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Real-Time  Software  Engineering  in  Ada: 
Observations  and  Guidelines 


Abstract:  Two  important  aspects  of  developing  a  real-time  system  are  controlling 
devices  and  managing  concurrency.  In  this  report,  we  present  several  techniques 
for  controlling  devices  with  Ada  and  several  Ada  tasking  paradigms  for  managing 
concurrency.  The  material  presented  in  this  report  is  taken  from  our  experiences 
in  developing  a  real-time  embedded  system  in  Ada,  and  we  use  examples  from 
this  system  to  illustrate  the  various  methods  we  present.  We  begin  by  describing 
our  experiences  using  Ada  to  control  devices.  Specifically,  we  identify  issues  re¬ 
lated  to  accessing  device  registers  and  handling  interrupts,  and  present  tech¬ 
niques  for  dealing  with  such  issues.  We  then  recount  our  experiences  using  Ada 
to  manage  concurrency.  Specifically,  we  present  coding  paradigms  for  im¬ 
plementing  periodicity  and  constructing  synchronization  mechanisms.  We  il¬ 
lustrate  analytical  methods  for  determining  the  schedulability  of  a  task  set.  We 
then  discuss  the  effect  of  aperiodic  processing  requirements  on  the  schedulability 
of  a  task  set. 


1.  Introduction 

A  fundamental  goal  of  the  Real-Time  Embedded  Systems  Testbed  (REST)  Project  at  the 
SEI  is  to  examine  Ada  technology  from  a  real-time  systems  perspective.  Our  basic  strategy 
has  been  to  define  a  representative  real-time  embedded  problem,  develop  the  system  in 
Ada,  and  make  observations  along  the  way.  This  strategy  has  resulted  in  a  real-time  Ada 
artifact  that  has  provided  us  with  many  insights  into  real-time  programming  issues  and  the 
state  of  Ada  technology. 

Our  development  effort  was  atypical  for  various  reasons.  First,  the  purpose  of  the  effort  was 
to  experiment  with  real-time  systems,  not  to  deliver  a  real-time  system.  Second,  certain  Ada 
features  are  sometimes  not  used  to  avoid  the  risks  associated  with  them.  We  chose  instead 
to  exercise  these  features  to  explore  their  efficacy  in  developing  real-time  systems.  For 
example,  we  believe  the  use  of  Ada  tasking  separates  this  effort  from  other  early  real-time 
Ada  efforts.  Finally,  a  close  association  with  the  Advanced  Real-Time  Technology  (ART) 
Project  within  Carnegie  Mellon  University’s  School  of  Computer  Science  and  with  the  Real- 
Time  Scheduling  in  Ada  (RTSIA)  Project  at  the  SEI  has  allowed  us  to  use  the  latest  in  ana¬ 
lytical  methods  whenever  possible. 

This  report1  presents  a  set  of  observations  and  guidelines  drawn  from  our  experiences  in 
developing  the  Ada  artifact.  Specific  emphases  are  placed  on  controlling  devices,  managing 
concurrency  through  the  use  of  Ada  tasking,  and  applying  analytical  methods  to  predict  and 


’The  following  reviewers  provided  many  valuable  comments  and  suggestions:  Neal  Altman,  Nancy  Belz  Rich 
D'lppolito,  Pat  Donohoe,  Ken  Fowler,  Michael  Gagliardi,  John  Goodenough,  Tim  McCardle,  Ragunathan  Raj- 
kumar,  Lui  Sha,  Roger  Van  Scoy,  and  Nelson  Weiderman. 
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understand  the  runtime  behavior  of  Ada  software  in  a  deadline-driven  environment.  Three 
classes  of  tasks  are  introduced:  periodics,  servers,  and  aperiodics.  Analytical  methods  ap¬ 
plicable  to  periodics  and  servers  are  also  presented.  An  extended  example  drawn  from  the 
artifact  is  used  to  illustrate  the  various  analytical  methods.  The  conclusion  summarizes  the 
major  lessons  we  have  learned. 


2 
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2.  Controlling  Devices  Using  Ada 

A  common  characteristic  of  real-time  systems  is  a  strong  reliance  on  time-critical  inter¬ 
actions  (e.g.t  input  and  output)  with  a  set  of  potentially  heterogeneous  devices.  To  control 
devices  through  application  code,  one  must  be  able  to: 

1 .  Map  data  types  efficiently  and  accurately  onto  an  underlying  machine’s  ar¬ 
chitecture  to  access  I/O  memory  (e.g.,  device  registers). 

2.  Enable,  disable,  and/or  handle  device  interrupts. 

The  following  subsections  discuss  several  of  our  experiences  and  offer  recommendations 
about  how  to  use  the  Ada  programming  language  to  implement  these  two  types  of  required 
capabilities.  Although  we  realize  that  using  assembly  language  to  control  devices  is  always 
a  viable  alternative  to  using  Ada,  our  intent  is  to  illustrate  how  Ada  could  be  used  to  achieve 
the  same  functionality. 


2.1.  Accessing  Device  Registers 

To  control  a  hardware  device,  you  must  be  able  to  access  its  register  set.  Ada  provides 
representation  clauses  that  allow  you  to  specify  the  layout  of  data  types  to  represent  device 
registers.  In  particular,  Ada  representation  clauses  allow  you  to  specify  the  storage  layout  of 
a  record  type,  including  the  alignment,  order,  storage  location,  bit  positions  within  the 
storage  location,  and  size  of  the  components.  The  record  representation  clause,  in  combi¬ 
nation  with  a  length  clause,  allows  you  to  specify  precisely  defined  data  structures  for  inter¬ 
facing  with  hardware  devices.  For  example,  Figure  2-1  demonstrates  the  use  of  a  record 
representation  clause,  length  clause,  and  address  clause  to  define  the  structure,  size,  and 
memory  location  of  a  receiver  buffer  register  for  a  serial  communications  device. 

The  length  clause  used  in  Figure  2-1  guarantees  that  exactly  16  bits  will  be  used  for 
representing  the  buffer  register.  Additionally,  this  code  segment  defines  RX_Buffer,  a  vari¬ 
able  to  store  the  contents  of  the  device's  receiver  buffer  register.  An  Ada  address  clause 
immediately  follows  the  declaration  of  the  RX_Buffer  variable  i.i  Figure  2-1 .  This  address 
clause  specifies  an  address  in  memory  to  which  the  RX_Buffer  variable  is  to  be  mapped.  In 
this  example,  Memory_Address  is  an  instantiation  of  Unchecked_Conversion  that  converts 
an  unsigned  word  into  an  address. 

Accessing  device  registers  using  Ada  involves  issues  other  than  just  correct  data  represen¬ 
tation.  The  following  list,  which  is  summarized  from  our  experiences  in  developing  an  appli¬ 
cation  for  an  inertial  navigation  system  (INS)  simulator  [9,  8],  contains  some  of  the  most  im¬ 
portant  observations  we  made  when  using  Ada  to  read  and  write  device  registers. 

1 .  If  the  memory  location  of  a  device  register  is  known  at  compile  time  then  the 
example  code  shown  in  Figure  2-1  is  applicable  However,  if  the  device 
register  address  is  not  known  until  runtime  (e.g.,  it  is  returned  from  a  kernel 
service  call),  a  different  approach  must  be  used  to  access  the  register.  In 
such  a  case,  an  Ada  subprogram  (or  a  declare  block)  with  local  variables, 
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typ*  Byt*  la  rang*  0..16#FF#; 

typ*  Lln*_Numb*r_Typ*  is  rang*  0 . . 16#3#; 


typ*  R*c*iv*r_Buff*r  ia  racord 
R*c*iv*_Char  :  Byt*; 

R*c*iv*r_Lin*_Numbar  :  Lin*_Nuiob*r_Typ*; 

Parity_Error  :  BOOLEAN; 

Fraaing_Error  :  BOOLEAN; 

Ov*rrun_Error  ;  BOOLEAN; 

Data_Valid  :  BOOLEAN; 

•nd  racord; 

for  Racaiv*r_Buf far  us*  racord  at  mod  7, 
R*c*iv*_Char  at  0  rang*  0 . . 7 ; 

R*c*iv*r_L±n*_Numbar  at  0  rang*  8.. 9; 

Parity_Error  at  0  rang*  12.. 3  2; 

Framlng_Error  at  0  rang*  13.. 13; 

Ov*rrun_Error  at  0  rang*  14.. 14; 

Data_Valid  at  0  rang*  15.. 15; 

•nd  racord; 

for  R*c*iv*r_Buf far' SIZE  us*  16; 

RX_Buff*r  ;  R*c*iv*r_Buf f*r; 

for  RX_Buff*r  us*  at  H*mory_Addr*s ■ (16#00FF_0000#) ; 

Figure  2-1 :  Receiver  Buffer  Representation  Clause 


whose  memory  locations  are  specified  via  dynamic  address  clauses,  provides 
an  effective  way  of  accessing  data  stored  in  particular  locations  of  memory. 
The  example  code  shown  in  Figure  2-2  illustrates  this  technique,  us:ng  a  func¬ 
tion  and  a  dynamic  address  clause  for  the  RX_Buffer  variable  shown  earlier  in 
Figure  2-1 .  In  Figure  2-2,  the  address  of  the  receiver  buffer  register  is  passed 
as  a  parameter  and  is  used  in  a  dynamic  address  ciause  to  map  the  local 
variable  RX_Bufrer  to  the  memory  location  corresponding  to  the  device’s  data 
register.  An  alternative  approach  to  using  a  dynamic  address  clause  is  to  use 
an  access  variable  (i.e.,  a  pointer  to  an  object  of  type  Receiver_Buffer)  and 
assign  the  pointer  a  value  (address)  at  ri  -dime.2 

2.  Some  hardware  devices  have  registers  that  serve  a  dual  (read/write)  purpose. 
For  such  registers,  different  register  layouts  are  used  for  reading  and  wri:,ng. 
These  special  dual-purpose  device  registers  can  be  modeled  in  Ada  as  two 
different  device  registers.  Using  the  approach  outlined  in  Figure  2-1 ,  you  can 
define  two  local  vaiiat'e"  and  use  two  address  clauses  ’o  specify  the  same 
memory  location  to  represent  the  read  and  write  view  of  the  register  for  read- 


v. 


2This  approach  assumes  that  you  can  perform  an  unchecked  conversion  from  an  address  to  the  appropriat 
access  type . 
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ing  and  writing  the  register’s  contents.3  One  alternative  to  this  overlaying  of 
variables  with  different  types  is  to  use  one  additional  variable  declared  as  an 
unsigned  integer  type  (having  the  same  number  of  bits  as  the  device  register) 
through  which  I/O  operations  can  be  performed.  However,  using  this  ap¬ 
proach  introduces  the  need  to  do  unchecked  conversions  from  the  unsigned 
type  to  the  read  register  type  (for  reading)  and  from  the  write  register  type  to 
the  unsigned  type  (for  writing)  to  access  the  device  register. 

3.  Some  hardware  architectures  restrict  the  kinds  of  machine  instructions  that 
can  be  used  for  accessing  device  registers.  For  example,  some  devices  are 
only  word  addressable  and  will  produce  erroneous  results  if  accessed  through 
bit  field  instructions  [1].  You  should  be  aware  of  any  such  device  access 
restrictions  and  inspect  your  generated  code  to  check  for  any  such  instructions 
that  might  violate  those  restrictions. 

4.  You  should  be  aware  of  any  global  code  optimizations  that  might  eliminate 
important  assignment  statements  being  used  to  control  a  device.  For  ex¬ 
ample,  many  hardware  devices  require  explicit  initialization  sequences  that 
can  involve  a  sequence  of  assignments  to  the  same  device  control  register. 
To  a  global  optimizer,  some  of  these  assignment  statements  may  appear  to  be 
redundant  (through  variable  definition  or  use  analysis)  and  therefore  would  be 
eliminated.  But  eliminating  such  assignment  statements  can  effect  the  opera¬ 
tional  correctness  of  your  code. 


function  G«t_Cbaractar  (RX_Buf f«r_Addraaa  :  in  ADDRESS) 
rat urn  CHARACTER  is 


—  Map  variable  RX_Buffor  to  serial  I/O  device's  receive  buffer 

—  using  a  dynamic  address  clause. 


RMd_Charact«r  :  CHARACTER  : ■  ASCI I. NOT. ; 
RX_Buff«r  :  Racaiv«r_Buff«r; 

for  RXJBuffer  usa  mt  RX_Buffar_Add rass; 
begin 

if  RX  Buffer. Data  Valid  than 


—  Assumes  an  8  bit  CHARACTER  type  representation;  otherwise 

—  a  potential  data  size  mismatch  could  occur  for  the  conversion. 


Raad_Character  : ” 

Convert_To_Char (RX_Buf far . Receive_Char) ; 

and  if; 

return  Read_Character; 
and  Get_Character; 

Figure  2-2:  Using  a  Dynamic  Address  Clause  to 
Access  a  Device  Register 


3ln  effect,  this  approach  overlays  two  separate  data  objects  onto  the  same  memory  address.  Although  the 
Ada  Language  Reference  Manual  (LRM)  [20]  states  that  overlaying  objects  is  erroneous,  some  Ada  implemen¬ 
tations  do  support  it.  Here,  erroneous  means  that  the  runtime  behavior  of  this  code  cannot  be  guaranteed  across 
Ada  implementations. 
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2.2.  Interrupt  Handling 

To  handle  hardware  interrupts  in  application  software,  Ada  defines  task  interrupt  entries, 
which  enable  binding,  via  an  address  clause,  of  a  hardware  interrupt  to  a  task  entry.  The 
semantics  of  the  interrupt  handling  model  described  in  the  Ada  Language  Reference  Manual 
(LRM)  [20]  state  that  an  interrupt  acts  as  an  entry  call  made  from  a  conceptual  hardware 
task  whose  priority  is  higher  than  the  main  program  and  any  other  user-defined  task.  How¬ 
ever,  the  LRM  does  not  specify  the  type  of  entry  call  which  must  be  made  to  interrupt 
entries,  but  rather  gives  implementors  the  freedom  to  implement  any  calling  mechanism 
(e.g.,  normal  entry  call,  conditional  entry  call)  provided  that  it  preserves  the  above  seman¬ 
tics.  Figure  2-3  illustrates  a  generic  interrupt  handler  task  written  in  the  spirit  of  Ada  that 
builds  on  the  example  code  shown  in  Figures  2-1  and  2-2. 


task  K«yboaxd_Watchar  is 
antry  Char set ar_£nts rad; 

for  Charactar_Entarad  usa  at  RX_Xntarrupt_Addrass; 
and  Keyboard JWat char; 

task  body  Kayboard_Watchar  is 
My_Charactar  :  CHARACTER; 
begin 
loop 

accept  Character_Entered  do 

MyjCharacter  :■  Get_Charactar (RX_Buf£ar_Address) ; 
Placa_Character_ln_Buffan 
Reset_RXJntempt; 
end  CharactarJBntared; 
end  loop; 

end  KayboardJWatcher; 

Flgure  2-3:  Interrupt  Handling  Ada  Task 


In  this  example,  the  Keyboard_Watcher  task  has  an  entry  named  Character_Entered,  which 
is  bound  to  the  receiver  interrupt  of  a  serial  I/O  device.  When  a  receiver  interrupt  occurs,  an 
entry  call  to  Character_Entered  will  be  made.  Within  the  accept  body,  a  call  to  the 
Get_Character  function  of  Figure  2-2  is  made  to  fetch  a  character  from  the  receiver  buffer 
register.  Since  the  language  definition  does  not  specify  how  the  entry  call  to 
Character_Entered  is  to  be  implemented,  Ada  implementations  can  vary  in  how  they 
achieve  this  call. 

It  has  been  our  experience  that  the  techniques  employed  for  implementing  Ada  interrupt 
entry  calls  vary  along  at  least  two  dimensions: 

1 .  When  the  entry  call  is  made  relative  to  the  time  of  the  interrupt  event.  In  gen¬ 
eral,  the  interrupt  entry  call  can  be  made  immediately  upon  receipt  of  the  inter¬ 
rupt  or  it  can  be  deferred. 

2.  How  the  entry  call  is  achieved,  i.e.,  what  kind  of  synchronization  mechanism  is 
used.  For  example,  the  interrupt  entry  call  can  be  either  a  normal,  conditional, 
or  timed  entry  call. 
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Some  of  the  Ada  interrupt  handling  implementation  schemes  we  have  encountered  are  sum 
marized  below. 


# 


1.  Interrupt  Service  Routine  (ISR):  The  !SR  interrupt  handling  scheme  involves 
using  an  Ada  procedure  for  handling  hardware  interrupts.  Under  this  ap¬ 
proach,  the  address  of  an  Ada  subprogram  (ISR)  is  stored  as  the  interrupt 
vector  for  the  hardware  device.  When  the  device  interrupts,  the  interrupt  han¬ 
dling  logic  of  the  CPU  sets  the  program  counter  to  the  starting  address  of  the 
ISR,  and  thus  effects  a  subroutine  call  to  the  ISR.  Typically,  this  approach  has 
the  least  amount  of  runtime  overhead,  but  this  minimal  overhead  may  come  at 
the  expense  of  flexibility  within  the  ISR  procedure.  For  example,  common 
restrictions  on  ISR  code  include:  no  task  entry  calls,  no  calls  to  TextJO  sub¬ 
programs,  and  limited  access  to  the  user’s  data  space.  Of  the  Ada  interrupt 
handling  models  discussed  in  this  paper,  the  ISR  approach  is  the  only  one  that 
isn’t  patterned  after  the  LRM  model  in  some  way,  since  an  Ada  task  is  not 
used  to  handle  the  device  interrupt.  Normally,  however,  the  ISR  code  can  call 
an  implementation-dependent  signaling  primitive  to  synchronize  with  applica¬ 
tion  tasks,  and  therefore  achieve  the  effect  of  an  Ada  interrupt  task.  Note  that 
this  task  synchronization  is  not  immediate,  but  rather  occurs  from  within  the 
runtime  kernel  to  the  application  task  some  time  after  the  interrupt  has  been 
completely  handled. 

2.  Deferred  Runtime  Signal  Mechanism:  The  deferred  runtime  signal  approach 
implements  the  semantics  of  an  Ada  interrupt  entry  by  using  a  runtime  signal 
primitive,  rather  than  a  full  Ada  rendezvous,  to  effect  a  call  to  the  interrupt  han¬ 
dling  task.  When  an  interrupt  occurs  under  this  scheme,  a  runtime  system 
ISR  posts  a  signal  and  completes  its  execution.  The  runtime  system  sub¬ 
sequently  maps  that  signal  into  a  call  to  the  interrupt  task’s  entry.  The  main 
advantage  of  this  approach  is  the  minimal  runtime  overhead  needed  to  service 
the  interrupt.  Notice  that  in  this  model,  servicing  the  interrupt  does  not  include 
executing  the  interrupt  entry’s  accept  body.  Generally,  this  model  does  not 
limit  the  operations  that  can  be  performed  in  the  interrupt  task.  However,  task¬ 
ing  optimizations  often  can  be  performed  when  certain  guidelines  are  followed 
within  the  task  body. 

3.  Ada  Rendezvous  Mechanism:  This  approach  is  suggested  in  the  LRM  and 
uses  an  Ada  rendezvous  to  call  the  interrupt  handling  task.  When  an  interrupt 
occurs,  the  runtime  makes  an  Ada  entry  call  to  the  interrupt  task  as  part  of 
dispatching  the  interrupt.  Since  a  normal  Ada  entry  call  can  potentially  block, 
some  Ada  implementations  use  a  conditional  entry  call  for  calling  interrupt  task 
entries.  For  example,  the  TeleGen2  3.23  Vax/VMS  to  MC68020  cross- 
compiler  provides  the  user  with  a  capability  for  defining  a  "failure"  task  to  be 
called  if  the  interrupt  task  cannot  immediately  accept  the  interrupt  entry  call. 
The  main  advantages  of  this  approach  are  portability  and  the  lack  of  any 
restrictions  on  code  in  the  interrupt  task. 

Nevertheless,  because  this  scheme  uses  an  Ada  rendezvous  for  synchroniz¬ 
ing  with  the  interrupt  task,  it  has  more  runtime  overhead  than  the  other  ap¬ 
proaches.  However,  optimized  interrupt  entry  calls  are  possible  when  the  ap¬ 
plication  task  code  follows  certain  coding  restrictions.  For  example,  the  VADS 
5.7  Sun/UNix  to  MC68020  cross-compiler  has  a  passive  task  scheme  that 
implements  the  semantics  of  an  Ada  interrupt  entry  by  using  compiler  op¬ 
timizations  that  treat  the  code  inside  the  accept  body  of  the  interrupt  entry  as  a 
subprogram  protected  by  a  semaphore. 
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2.3.  Recommendations 


Although  representation  clauses  are  part  of  the  language  definition,  only  recently  has  the 
Ada  Compiler  Validation  Capability  (ACVC)  (suite  1.10)  begun  to  test  Ada  implementations 
for  compliance  to  Chapter  13  of  the  Ada  Language  Reference  Manual.  Unfortunately,  most 
of  these  added  ACVC  tests  check  to  ensure  that  syntactically  illegal  clauses  are  rejected; 
only  a  few  of  the  tests  actually  check  for  the  presence  of  representation  clause  functionality. 
As  a  consequence  of  this  inadequate  testing  in  the  ACVC  suite,  the  extent  and  reliability  to 
which  compilers  implement  the  features  defined  in  Chapter  13  of  the  LRM  varies  con¬ 
siderably.  Our  recommendations  for  controlling  devices  in  Ada  are  summarized  below. 

1.  Determine  representation  specification  restrictions.  Determine  if  your 
compiler  provides  sufficient  support  to  handle  the  range  of  external  interface 
specifications  expected  for  your  application.  In  particular,  determine  whether 
or  not  representation  clauses  are  supported,  and  if  so,  what  restrictions  on 
their  use  are  dictated  by  your  Ada  implementation.4  For  instance,  if  your  Ada 
implementation  does  not  support  representation  specifications  at  the  bit  level, 
then  writing  device  controlling  code  in  Ada  will  be  difficult.  Also,  know  if  your 
Ada  implementation  imposes  any  restrictions  with  respect  to  aligning  data 
records  in  memory.  Some  hardware  devices  are  strictly  odd-  or  even-word 
addressable;  furthermore,  across  various  devices,  register  sizes  often  vary  be¬ 
tween  8, 16,  or  32  bits. 

2.  Verify  data  structure  representation.  Verify  that  your  representation 
clauses  are  Implemented  as  expected.  Having  a  technique  (e.g.,  inspecting 
the  generated  code)  for  verifying  that  your  data  structures  are  being 
represented  correctly  is  essential.  Know  how  your  Ada  implementation’s 
scheme  for  numbering  bytes,  words,  and  long  words  maps  onto  the  target’s 
data  organization  in  memory.  Also,  an  important  implementation  detail  is 
whether  your  Ada  compiler  uses  a  left-to-right  or  right-to-left  bit  field  ordering 
scheme  for  its  record  representation  clauses.  Additionally,  unsigned  types 
can  be  very  important  in  developing  code  to  control  a  hardware  device.  The 
critical  issue  here  is  to  ensure  that  an  exact  number  of  bits  will  be  used  for 
mapping  onto  a  device  register  defined  in  the  I/O  address  space. 

3.  Assess  the  efficiency  of  generated  code.  Besides  verifying  the  correctness 
of  the  generated  code,  consider  its  efficiency.  For  example,  does  the  code 
generator  use  the  least  expensive  instructions  for  accessing  bit  level  compo¬ 
nents  of  device  register  records? 

4.  Understand  the  syntax  and  semantics  of  Interrupt  entries.  Determine  if 
your  Ada  implementation  supports  interrupt  entries,  and  if  so,  what  implemen¬ 
tation  scheme(s)  they  use.  Be  aware  of  the  following  issues  when  using  Ada 
interrupt  entries. 

a.  Performance:  What  is  the  latency  from  the  time  the  hardware  interrupts 
until  the  code  in  the  Ada  interrupt  task  begins  executing?  How  much 
runtime  overhead  is  incurred  on  a  call  to  an  interrupt  entry?  How  long 


4 The  Ada  Language  Reference  Manual  requires  that  a  list  of  all  restrictions  on  representation  clauses  be 
provided  in  Appendix  F. 
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are  interrupts  disabled  by  the  runtime  system  during  interrupt  process¬ 
ing? 

b.  Implementation  restrictions:  What  restrictions  have  been  placed  on  in¬ 
terrupt  tasks?  Can  they  be  called  from  the  application  code?  Can  they 
perform  I/O  operations?  Can  they  share  data  with  other  pieces  of  ap¬ 
plications  code?  Can  they  make  entry  calls  to  other  tasks?  What  type 
of  interrupt  entry  call  is  made  when  a  interrupt  occurs:  normal  Ada 
entry  call,  timed  entry  call,  conditional  entry  call,  signal?  Are  interrupt 
entry  calls  queued  or  can  they  be  lost? 

5.  Consider  alternatives  to  Ada  Interrupt  entries.  If  your  Ada  implementation 
does  not  support  interrupt  entries  or  you  choose  not  to  use  them,  you  have 
some  other  options  as  summarized  below. 

a.  You  can  code  the  entire  interrupt  handler  (e.g.,  subprogram)  in  Ada 
and  associate  its  starting  memory  location  with  the  interrupt  either 
through  an  address  clause  or  by  calling  a  runtime  kernel  service. 

b.  You  can  perform  the  above  interrupt  linkage,  but  implement  the 
declared  Ada  interrupt  service  routine  in  another  language  (probably 
assembler)  and  use  either  pragma  INTERFACE  or  machine  code  in¬ 
sert  statements  for  the  subprogram  body. 

c.  You  can  rely  on  an  existing  device  driver  and  interrupt  service  routine 
to  handle  device  interrupts. 

Of  course,  to  fully  support  the  semantics  of  an  Ada  interrupt  entry  call  these 
ISRs  would  need  to  have  a  signaling  capability  in  order  to  synchronize  with 
application  level  tasks. 
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3.  Managing  Concurrency  in  Ada 

There  are  two  fundamental  methods  for  managing  concurrency  on  a  single  processor: 

1 .  Through  the  use  of  time-division  multiplexing  (e.g.,  a  cyclic  executive). 

2.  Through  the  use  of  a  preemptive  scheduling  mechanism. 

The  basic  tradeoff  between  these  two  approaches  is  complexity  and  maintainability  of  appli¬ 
cation  design  versus  nondeterminism  of  execution  timing  behavior.  The  manual  dissection 
and  multiplexing  of  execution  threads,  which  is  necessary  for  designing  and  maintaining  a 
cyclic  executive,  may  be  a  difficult  task;  however,  the  resulting  execution  timing  behavior  is 
basically  deterministic.  The  reverse  is  true  for  a  preemptive  scheduler,  which  allows  for  the 
separation  of  scheduling  and  functional  aspects  of  the  program  but  introduces  nondeter¬ 
minism  into  the  timing  behavior.  Ada  tasking  provides  a  vehicle  for  separating  scheduling 
and  functional  concerns.  The  use  of  Ada  tasking  in  conjunction  with  analytical  methods 
based  on  scheduling  theory  allows  us  to  maintain  this  separation  and  at  the  same  time 
predict  and  understand  an  Ada  program’s  timing  behavior. 

This  section  offers  guidelines  for  using  Ada  tasks  to  construct  real-time  software  that  will 
execute  in  an  understandable  and  predictable  manner.  Following  the  spirit  of  Sha  [1 7],  we 
have  grouped  tasks  into  three  major  categories:  periodics,  servers,  and  aperiodics.  We 
compare  and  contrast  several  design  paradigms  for  periodics  and  servers,  and  illustrate  as¬ 
sociated  techniques  for  performing  schedulability  analysis.  Aperiodics  are  then  briefly  dis¬ 
cussed  with  an  emphasis  on  how  they  affect  the  schedulability  of  a  task  set.  Finally,  we 
offer  a  set  of  recommendations  based  on  our  experiences. 


3.1.  Periodic  Tasks 

Periodic  processing  requirements  with  hard  deadlines5  are  common  in  real-time  systems 
(e.g.,  reading  a  device  and  sending  messages  at  a  specified  frequency).  Paradigms  that 
are  amenable  to  schedulability  analysis  are  needed  for  implementing  periodicity  in  order  to 
guarantee  that  rigorous  timing  requirements  will  always  be  satisfied.  The  following  subsec¬ 
tions  discuss  alternatives  for  performing  periodic  processing  in  Ada  and  illustrate  the  prac¬ 
tical  application  of  analytical  methods  to  a  periodic  task  set  extracted  from  an  INS  simulator 
[9.  8]. 


I 


SA  task’s  deadline  is  considered  to  be  hard  if  meeting  the  deadline  is  critical  to  the  system’s  operation.  On  the 
other  hand,  it  is  desirable  but  not  necessary  to  meet  a  soft  deadline  [1 9], 
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3.1.1.  Implementing  Periodic  Tasks 

For  this  discussion,  we  define  a  periodic  task  as  one  that  is  ready  to  execute  at  fixed  inter¬ 
vals  in  time  (or  periods)  and  must  complete  execution  before  the  end  of  the  interval  (which  is 
the  start  of  the  next  period).  We  outline  four  models  for  designing  periodic  tasks  in  Ada, 
summarizing  the  design  approach  of  each  model  and  commenting  on  them. 

Delay  Model 

The  most  widely  known  model  for  implementing  periodic  tasks  in  Ada,  and  the  one  that  is 
offered  in  the  Ada  LRM,  involves  using  Ada’s  delay  statement  as  shown  in  Figure  3-1 .  In 
this  approach,  the  periodic  tasks  operate  autonomously  in  an  endless  loop  by  performing 
their  computations,  computing  their  next  activation  time,  and  delaying  until  the  start  of  their 
next  period. 


task  body  P«riodic_Taak  is 

N«xfc_Tims  :  Calendar. Tima  :■  Task_Start_Tiraa; 
begin 

dalay  (Task_Start_Tima  -  Calandar .Clock) ; 
loop 

Do_Wor1<; 

Naxt_Tima  :■  Naxt_Tima  +  Task_Pariod; 
dalay  (Naxt_Tima  -  Calandar .Clock) ; 
and  loop; 

and  Pariodio__Task; 

Figure  3-1 :  Autonomous  Periodic  Task  Using  Ada  Delay 


A  major  drawback  with  this  approach  is  that  it  suffers  from  a  phenomenon  that  we  call  delay 
jitter,  which  occurs  when  a  task  is  preempted  between  the  time  the  clock  is  read  and  the 
time  at  which  the  delay  begins.  If  such  preemption  occurs,  the  preempted  task  will  start  its 
delay  later  than  it  should  and  effectively  postpone  the  starting  point  of  its  next  period. 

The  problem  caused  by  delay  jitter  can  be  significant  since  the  preemption  time  can  be  long. 
A  low-priority  periodic  task  could  be  preempted  for  the  entire  execution  time  of  a  higher  pri¬ 
ority  task.  There  are  circumstances  under  which  this  problem  will  result  in  the  task  missing 
deadlines.  Moreover,  this  phenomenon  alters  the  periodicity  of  the  task  and  thus  violates  a 
premise  used  in  the  analytical  techniques  described  later  in  this  report.  For  these  reasons, 
we  cannot  recommend  this  approach.  However,  there  may  be  circumstances  where  this 
approach  is  viable.  One  example  is  a  system  in  which  it  can  be  shown  that  deadlines  will  be 
met  even  in  the  presence  of  delay  jitter.  Additionally,  if  one  can  prevent  delay  jitter  by  en¬ 
suring  that  a  periodic  task  cannot  be  preempted  from  the  time  the  clock  is  read  until  the 
delay  is  started,  then  this  alternative  is  more  attractive.  However,  even  if  delay  jitter  is 
eliminated  in  this  manner,  the  model  still  incurs  the  overhead  of  using  Calendar.Clock.  The 
need  to  read  the  clock  is  inherent  in  using  delay  intervals  to  achieve  periodicity  [21].  Delay¬ 
ing  until  an  absolute  time  eliminates  this  problem. 
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Supervisor/Worker  Model 


A  slight  variation  of  the  previous  model  uses  pairs  of  tasks  to  achieve  periodic  processing  as 
shown  in  Figure  3-2.  In  this  approach,  each  periodic  (worker)  task  has  a  higher  priority 
supervisor  task  associated  with  it.  In  fact,  to  reduce  the  delay  jitter  inherent  in  the  previous 
model,  each  supervisor  task  has  a  priority  which  is  higher  than  all  worker  tasks;  therefore  a 
supervisor  cannot  be  preempted  by  a  worker.  The  priorities  of  the  supervisors  are  ordered 
based  on  the  priority  of  the  associated  worker  task.  Each  supervisor  task  is  responsible  for 
achieving  the  desired  periodic  execution.  The  worker  task  embodies  a  simple  endless  loop 
that  accepts  the  periodic  activation  calls  from  its  supervisor  and  then  performs  its  computa¬ 
tions. 


task  body  Pariodic_Sup«rvi*or  la 

N«xt_Tia*  :  Calendar. Tim*  : ”  Ta#k_Start_Tin»a ; 
begin 

delay  (Taak_Start_Time  -  Calendar. Clock) ; 

loop 

select 

Periodio_Task . Activate ; 

else 

Handle_Missod_Deadfina; 
end  select ; 

Nextjriae  :*  Next_Time  +  Task_Period; 
delay  (Next_Time  -  Calendar. Clock) ; 
and  loop; 

end  Seriodio_Supervisor; 

task  body  Feriodic_Task  is 
begin 
loop 

aacept  Activate; 

Do_Wori r; 
end  loop; 

end  Feriodic_Task; 

Figure  3-2:  Supervisor/Worker  Model 


The  preemption  time,  which  can  potentially  cause  delay  jitter,  is  bounded  in  this  model  be¬ 
cause  the  supervisor  tasks  perform  the  delaying  (on  behalf  of  their  workers)  and  because  a 
supervisor’s  only  work  is  to  periodically  activate  a  worker  task  via  an  entry  call.  Nonethe¬ 
less,  this  approach  still  suffers  from  the  delay  jitter  problem  because  the  supervisors  can 
preempt  each  other.  Additionally,  the  cost  of  an  extra  rendezvous  (to  activate  the  worker 
task)  is  introduced.  This  method  can  be  recommended  only  for  situations  in  which  the  ex¬ 
ecution  of  a  conditional  entry  call  is  an  insignificant  fraction  of  the  worker’s  period.  If  this  is 
the  case,  then  the  supervisor  can  detect  missed  deadlines  by  using  a  conditional  entry  call 
to  activate  its  associated  worker. 
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Task  Dispatcher  Model 

The  previous  model  requires  multiple  supervisor  tasks,  one  for  each  periodic  task.  This 
model  uses  only  one  supervisor  task  which  we  call  a  task  dispatcher.  The  task  dispatcher  is 
responsible  for  periodically  activating  all  worker  tasks.  One  method  for  implementing  a  task 
dispatcher  is  to  use  a  real-time  clock.  The  real-time  clock  serves  as  a  source  of  interrupts 
that  signal  the  task  dispatcher;  the  task  dispatcher,  in  turn,  activates  the  appropriate  periodic 
task(s).  An  example  demonstrating  this  scheme  is  shown  in  Figure  3-3. 


toak  body  P«riod±c_Diapatch«r  is 
bog  in 
loop 

sccspt  Clock_Intorrupt; 
loop 

Determine t_  Which_Periodic_  Task_  To_Activate; 
exit  ( When_NoJPeriodic_  Task_  To_Activate)  ; 

■•loot 

Poriodia_Task . Activate ; 

•Iso 

Handle_Missed_Deadline; 
end  soloct; 
end  loop; 

end  loop; 

end  Poriodic_Di spat choc; 

task  body  VeriodieJTask  is 
begin 
loop 

aaaopt  Activate; 

Do_  Work; 
end  loop; 

end  Poziodia_Task; 

Figure  3-3:  Real-Time  Ada  Task  Dispatcher 


In  this  approach,  the  task  dispatcher  receives  an  interrupt  from  a  real-time  clock  only  when  a 
periodic  task  (or  a  set  of  tasks)  should  be  activated.  The  dispatcher  task  iteratively  deter¬ 
mines  which  periodic  task  to  activate  and  makes  a  conditional  entry  call  to  that  task’s  Ac¬ 
tivate  entry.  If  this  conditional  entry  call  fails,  the  periodic  task  has  missed  a  deadline  and 
appropriate  action  can  be  taken.  Details  on  how  to  implement  this  periodic  tasking  scheme 
in  Ada  are  explained  by  Borger  [2]. 

There  are  several  advantages  to  this  approach.  First,  it  does  not  suffer  from  delay  jitter 
since  the  Periodic_Dispatcher  executes  at  the  highest  priority  and  consequently  will  not  suf¬ 
fer  from  preemption.6  Second,  it  allows  for  a  finer  notion  of  time  than  is  readily  available 


6We  assume  that  the  task  dispatcher  will  not  be  preempted  by  other  tasks  or  by  other  interrupts;  i.e.,  interrupts 
from  the  real-time  clock  never  will  be  masked.  We  also  assume  that  the  clock  automatically  rolls  over.  See 
[21]  for  a  discussion  of  drift  due  to  resetting  a  real-time  clock. 
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from  most  Ada  systems.  (For  example,  using  this  model  we  were  able  to  effectively  reduce 
our  resolution  of  time  from  10  ms  to  2.56  ms  for  the  INS.)  Finally,  this  is  a  solution  that  can 
be  used  today,  because  modifications  to  the  Ada  language  are  not  necessary;  it  only  re¬ 
quires  that  an  implementation  supports  interrupts  and  a  real-time  clock.  We  demonstrate 
the  application  of  scheduling  theory  to  this  technique  later  in  this  section. 

Nevertheless,  there  are  three  main  drawbacks  to  this  approach.  First,  the  task  dispatcher 
introduces  the  runtime  overhead  for  handling  the  clock  interrupts  and  activating  tasks  via  a 
conditional  entry  call.  Second,  the  application  programmer  must  play  a  role  (i.e.,  implement¬ 
ing  the  task  dispatcher)  in  managing  concurrency;  ideally,  this  function  should  be  abstracted 
out  of  the  application  program.  Finally,  a  real-time  clock  is  required.  The  last  model  to  be 
discussed  offers  a  relatively  simple,  efficient,  and  easy  to  use  approach  for  implementing 
periodic  tasks  in  Ada. 

Delay_UntII  Model 

An  improvement  over  all  the  previous  models,  which  is  discussed  by  Volz  [21],  is  to  code 
autonomous  periodic  tasks  using  a  DelayJJntil  absolute  time  mechanism  as  shown  in 
Figure  3-4. 


taak  body  P«riodio_T*«lc  ia 

N«xt_Tim  :  Calendar. Tim  Task_Start_Tim; 

bag  In 

dalayjuntil  (Ta«k_Start_Tim) ; 
loop 

Do_Work; 

Naxt_Tima  :■  Naxt_Tima  +  Taak_Pariod; 
bagin 

dalay_until  (Naxt_Tim)  ; 
axcaption 

whan  CALENDAR .  TIME_ERR0R  »>  Handlo_Missod_D9adline; 
and; 

and  loop; 

and  Pariodio_Task; 

Figure  3-4:  Autonomous  Periodic  Task 
Using  DelayJJntil  Mechanism 


This  model  is  similar  to  the  delay  model  in  that  the  periodic  tasks  operate  autonomously  in 
an  endless  loop.  The  task  delays  until  its  initial  start  time  and  then  becomes  ready  to  ex¬ 
ecute.  When  it  is  the  highest  priority  task  that  is  ready  to  execute,  it  enters  a  loop  and 
repeatedly  performs  its  computations,  computes  the  next  activation  time  based  on  the  previ¬ 
ous  schedule  time  and  the  task’s  period,  and  delays  until  the  start  of  its  next  period.  The 
DelayJJntil  mechanism  illustrated  above  has  built-in  semantics  stating  that  if  the  specified 
absolute  time  has  already  passed  at  the  time  of  the  DelayJJntil  subprogram  call,  the 
Time_Error  exception  in  package  Calendar  will  be  raised.  Given  such  a  runtime  mecha¬ 
nism,  missed  deadline  detection  is  straightforward  to  implement  in  the  application  code. 
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The  DelayJJntil  model  does  not  suffer  from  delay  jitter.  For  the  delay  model  to  work,  the 
calculation  of  the  delay  duration  followed  by  the  start  of  the  delay  must  be  an  atomic  action. 
If  it  is  not  atomic,  delay  jitter  results.  The  Delay_Until  model  does  not  have  an  equivalent 
atomicity  requirement  since  the  DelayJJntil  is  based  on  absolute  time.  The  only  require¬ 
ment  is  for  the  DelayJJntil  statement  to  be  executed  before  that  absolute  time.  Although  it 
is  not  commonly  available,  we  have  been  working  with  an  Ada  system  that  supports  this 
mechanism. 

Several  techniques  for  implementing  periodicity  through  the  use  of  Ada  tasking  have  been 
discussed,  yet  we  still  need  a  guarantee  that  our  timing  requirements  will  be  met.  Analytical 
methods  can  offer  this  guarantee.  The  next  section  introduces  analytical  methods  that  allow 
us  to  reason  about  the  timing  characteristics  and  predict  the  timing  behavior  of  a  collection 
of  periodic  tasks. 

3.1.2.  Analyzing  the  Schedulability  of  Periodic  Tasks 

The  rate-monotonic  algorithm  (RMA)[12]  provides  a  foundation  for  analyzing  the 
schedulability  of  a  set  of  periodic  tasks.  This  algorithm  states  that  for  priority-based  preemp¬ 
tive  scheduling,  the  static  priority  assigned  to  a  periodic  task  is  determined  solely  by  its  fre¬ 
quency;  higher  frequency  tasks  are  assigned  higher  priorities  than  lower  frequency  tasks.  If 
this  rule  is  followed  then  all  tasks  are  guaranteed  to  meet  their  deadlines,  provided  that  CPU 
utilization  for  the  periodic  task  set  is  below  n{2UK-\),  where  n  is  the  number  of  tasks. 
7  Moreover,  this  algorithm  is  optimal;  that  is,  any  task  set  that  is  schedulable  using  another 
fixed  priority  algorithm  is  also  schedulable  using  the  RMA.  Since  Ada  uses  a  fixed  priority, 
preemptive  scheduling  discipline,  the  RMA  applies. 

Consider  the  periodic  tasks  from  the  INS  task  set  whose  task  periods  and  execution  times 
are  shown  in  Table  3-1 .8  Task  priorities  are  assigned  to  the  six  periodic  tasks  in  decreasing 
order,  with  Px  being  assigned  the  highest  priority  and  P6  being  assigned  the  lowest  priority. 


7n( 2l,n-l)  converges  to  0.69  as  the  number  of  tasks  is  increased. 

8In  Table  3-1,  the  task  periods  are  exact  whereas  the  execution  times  are  estimates  that  illustrate  the  various 
types  of  analyses  that  can  be  performed.  Since  this  is  ongoing  work,  the  actual  execution  times  are  still 
changing. 
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• 

Task 

Description 

Period 

Exec. 

UR 

n 

(T) 

(c,/r.) 

Pi 

Update  Ship  Attitude 

2.56  ms 

0.5  ms 

19.53% 

p2 

Update  Ship  Velocity 

40.96  ms 

5.0  ms 

12.21  % 

p2 

Send  Attitude  Message 

61.44  ms 

15.0  ms 

24.41  % 

• 

P4 

Send  Navigation  Message 

983.04  ms 

30.0  ms 

3.05  % 

ps 

Update  Console  Display 

1024.0  ms 

50.0  ms 

4.88  % 

p6 

Update  Ship  Position 

1280.0  ms 

1.0  ms 

0.08  % 

Table  3-1 :  Periodic  Tasks  from  the  INS 

The  total  utilization  for  this  task  set  is  64.16%,  so  the  task  set  is  schedulable  according  to 
the  RMA.9  This  is  a  very  easy  schedufability  test  to  apply.  However,  there  are  several 
practical  concerns  that  are  not  treated  by  the  algorithm.  These  limitations  include: 

1.  Context  switching  overhead  is  assumed  to  be  negligible. 

^  2.  The  overhead  required  to  activate  periodic  tasks  is  assumed  to  be  negligible. 

3.  The  RMA  assumes  that  tasks  do  not  interact. 

The  next  two  sections  discuss  techniques  for  including  context  switching  and  task  dispatch¬ 
ing  overheads  in  the  schedulability  analysis.  Section  3.2  discusses  the  effects  of  task 
•  synchronization  on  the  schedulability  of  the  periodic  tasks. 

Including  Context  Switching  Overhead  in  the  Analysis 


Task  switching  time  can  be  introduced  into  the  utilization  calculation  by  adding  it  to  task 
execution  time  [1 8].  When  a  task  preempts  a  lower  priority  task,  a  context  switch  saves  the 
state  of  the  lower  priority  task  and  establishes  the  execution  state  (e.g.,  register  values,  pro¬ 
gram  counter  and  stack  pointer)  of  the  higher  priority  task.  After  the  higher  priority  task 
completes  execution,  a  context  switch  restores  the  state  of  the  lower  priority  task.  If  Cs 
represents  this  context  switching  overhead  and  C,  is  the  execution  time  of  task  P(,  then 
Cf+2CS  is  the  new  execution  time  to  be  used  in  the  analysis.10  This  allows  us  to  make  the 
observation  that  the  example  task  set  in  Table  3-1  will  continue  to  be  schedulable  provided 
that  the  following  inequality  is  satisfied. 


^Utilization  is  calculated  by 
n  c 

"-Ir 

i=l  i 

where  C(  and  Ti  represent  the  execution  time  and  the  period  of  task  P{,  respectively. 


,0Note  that  this  treatment  of  context  switching  overhead  assumes  perfect  preemptability  (i.e.,  that  the  runtime 
may  itself  be  preempted  during  a  context  switch).  Perfect  preemptability  is  an  assumption  of  rate-monotonic 
theory.  In  the  event  that  the  runtime  system  does  not  exhibit  perfect  preemptability,  we  can  use  the  techniques 
for  handling  blocking  time  that  are  discussed  later. 
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(0.5 +2C.)  (5.0+2 Ct)  (15.0 +  2CJ  (30.0+20)  (50.0 +2Cr)  (0.8+2 C.) 

-2.5^+ToHi+-^t-m^+Tc5W-+-imofs6<2  <M>=0734 


Using  the  above  inequality  and  solving  for  Cs  we  find  that  the  periodic  tasks  can  sustain 
0.106  ms  of  context  switching  overhead  and  remain  schedulable.  Note  that  the  RMA  uses  a 
pessimistic  utilization  bound  which  is  based  upon  a  worst-case  analysis.  It  has  been  shown 
in  [10]  that  on  the  average  the  RMA  can  schedule  task  sets  with  88%  periodic  utilization.  In 
fact,  this  task  set  can  sustain  significantly  more  overhead  and  remain  schedulable  as  is 
shown  below. 


A  necessary  and  sufficient  condition  for  the  schedulability  of  a  periodic  task  set  (allowing  for 
any  possible  task  phasing)  is  also  provided  in  [10].  In  essence,  this  schedulability  test  re¬ 
quires  that  each  task  be  examined  to  ensure  that  it  can  meet  its  first  deadline  when  all  tasks 
are  started  at  the  same  time  (which  has  been  shown  to  be  the  worst  task  phasing  [12]).  For 
each  particular  task,  this  is  accomplished  by  numerically  determining  if  there  is  sufficient 
time  to  allow  the  task  to  meet  its  first  deadline  [1 8].  In  the  following  example  we  will  use  the 
same  technique  to  illustrate  a  method  for  determining  the  absolute  maximum  amount  of 
overhead  sustainable  by  the  INS  periodic  task  set. 

Consider  task  Px.  The  following  inequality  tests  if  task  Px  can  sustain  the  2 Cs  units  of  over¬ 
head  and  still  meet  its  deadline. 

C1+2CJ<T,  =>  0.5  +  2C,  S2.56  =>  Cs=l.03ms 
Solving  for  Cs,  we  determine  that  it  will  remain  schedulable  provided  that  context  switching 
overhead  does  not  exceed  1 .03  ms. 


Consider  task  P2.  The  strategy  for  this  task  is  to  determine  if  there  is  a  point  in  time  be¬ 
tween  time  r=0  and  time  t=T2,  the  end  of  the  period  of  P2,  such  that  P2  has  completed  its 
execution.  For  each  scheduling  point  (i.e.,  the  starting  pcint  of  each  task’s  period),  we  must 
determine  if  the  execution  of  task  Px  to  that  point  and  the  execution  of  all  of  P2  (including 
overhead)  have  completed.  For  example,  the  first  inequality  below  tests  whether  the  execu¬ 
tion  of  Px  and  P2  have  completed  by  time  r=7,.  The  second  inequality  tests  whether  Px  has 
executed  twice  and  P2  has  completed  by  time  t=2Tx.  We  continue  in  this  fashion  until  all 
scheduling  points  from  time  r=0  to  the  end  of  the  period  of  P2  have  bean  examined.  The 
goal  is  to  determine  the  maximum  Cs  such  that  at  least  one  of  the  following  inequalities 
holds: 

(C1  +  2C,)  +  (C2+2C,)S  Tx  =>  (0.5  +  2C,)  +  (5.0+2C,)<  2.56  =*  Cs  <  0,  or 

2(C ,  +  2C,)  +  (C2  +  2CS)  S  27,  =>  2(0.5  +  20,)  + (5.0 +2C,)  <  5.12  =>  O,  <  0,  or 

3(C,+2C,)+(C2+2C,)S  37,  =>  3(0.5  +  2C,)+ (5.0  +  2C,)  S  7.68  =>  C,= 0.148  m,  or 


16(C,+2CJ)  +  (C2  +  2CJ)  S  167,  =>  16(0.5  +  2C,)  +  (5.0+  2C,)  S  40.%  =>  Cs  =  0.822 ms,  or 
16(C,  +  2CJ)+(C2  +  2CJ)  <  72  =>  16(0.5 +  2C,)  + (5.0+ 2C,)  <  40.%  =>  Cs= 0.822  ms 


Cs  would  have  to  be  negative  for  the  first  and  second  inequality  to  be  true.  The  third  ine¬ 
quality  can  sustain  a  positive  Cs.  The  last  two  inequalities  can  sustain  the  largest  Cs.  Notice 
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that  since  the  first  two  tasks  are  harmonic,  the  last  two  inequalities  are  identical.  P2  will 
remain  schedulable  provided  that  context  switching  overhead  does  not  exceed  0.822  ms. 
For  the  first  two  tasks  to  remain  schedulable,  the  maximum  amount  of  sustainable  overhead 
will  be  the  minimum  of  the  overheads  calculated  for  Px  and  P2. 

Table  3-2  lists  the  the  maximum  overhead  sustainable  by  each  task.  To  determine  the  max¬ 
imum  sustainable  overhead  by  the  periodic  task  set,  we  take  the  minimum  of  all  of  the  listed 
numbers,  which  is  0.41  ms.  This  is  a  significant  improvement  over  the  previous  calculation 
of  0.106  ms. 


Task 

Maximum 

Px 

1.03  ms 

P  2 

0.82  ms 

Pi 

0.45  ms 

Pa 

0.47  ms 

P$ 

0.41  ms 

P6 

0.41  ms 

Table  3-2:  Maximum  Sustainable  Context 
Switching  for  Each  Task 

Analyzing  the  Task  Dispatching  Mechanism 

The  INS  uses  a  real-time  clock  and  associated  task  dispatcher  to  precisely  schedule  the  six 
periodic  tasks  in  the  task  set.  This  raises  two  questions: 

•  How  can  the  task  dispatcher  be  modeled  analytically? 

•  How  does  the  task  dispatcher  affect  the  schedu lability  of  the  periodic  tasks? 

Assume  that  the  task  dispatcher  has  an  Ada  priority  greater  than  that  of  Px,  the  highest 
priority  task  in  the  task  set.  Since  the  task  dispatcher  executes  once  each  time  a  periodic 
task  is  to  be  activated  (and  no  more  often  than  that),  we  can  treat  the  execution  time  of  the 
task  dispatcher  as  additional  execution  time  on  behalf  of  each  periodic  task.  However,  it  is 
important  to  emphasize  that  this  additional  execution  time  occurs  at  the  highest  priority. 
Thus,  the  dispatching  of  a  lower  priority  task  can  temporarily  block  the  execution  of  a  higher 
priority  task.  We  must  be  careful  to  account  for  these  blocking  effects  in  addition  to  the 
preemption  effects. 

Preemption  occurs  naturally  when  a  low-priority  task  is  delayed  by  the  execution  of  a  higher 
priority  task.  In  contrast,  blocking  occurs  when  a  high-priority  task  is  delayed  by  the  execu¬ 
tion  of  a  lower  priority  task.  In  the  context  of  the  task  dispatching  analysis,  blocking  may 
occur  when  tasks  are  activated.  For  example,  since  the  execution  time  of  the  dispatcher 
when  activating  P3  is  considered  additional  execution  time  on  behalf  of  Pv  then  P2  can  effec¬ 
tively  block  both  Px  and  P2  because  P3  is  a  lower  priority  task.  Therefore,  the  time  taken 
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from  Px  and  P2  when  P3  is  activated  must  be  considered  blocking  time.  To  treat  the  task 
dispatching  mechanism  analytically,  we  must  also  account  for  the  blocking  time  resulting 
from  the  dispatching  of  periodic  tasks. 

Now  consider  the  case  of  Pv  When  the  task  dispatcher  activates  P,.  the  execution  time  of 
the  task  dispatcher  (referred  to  as  De)  can  be  modeled  as  additional  execution  time  on  be¬ 
half  of  Pr  But  in  the  worst  possible  case,  where  all  six  periodic  tasks  must  be  activated  at 
the  same  time,  the  task  dispatcher  must  execute  five  additional  times  to  activate  the  remain¬ 
ing  tasks.  Since  the  five  additional  iterations  of  the  task  dispatcher  are  on  behalf  of  lower 
priority  tasks,  Px  may  be  blocked  for  as  long  as  5 Db,  where  Db  represents  the  time  taken  by 
the  dispatcher  to  activate  a  lower  priority  task.  Continuing  the  analysis  in  this  manner,  we 
find  that  each  periodic  task  must  be  able  to  accommodate  additional  execution  time  due  to 
being  dispatched  (DJ11  and  blocking  time  caused  by  the  dispatching  of  all  lower  priority 
periodic  tasks  (a  multiple  of  Db ). 

The  analytical  techniques  for  independent  periodic  tasks  do  not  take  into  account  blocking 
time.  However,  it  has  been  shown  in  [1 6]  that  the  analytical  techniques  for  determining  the 
schedulability  of  a  set  of  independent  periodic  tasks  can  be  generalized  to  account  for  block¬ 
ing  time.  When  we  apply  these  analytical  techniques  to  the  problem  of  determining  the 
schedulability  of  the  periodic  tasks  in  the  presence  of  the  task  dispatcher,  we  find  that  the 
series  of  inequalities  shown  in  Figure  3-5  express  sufficient  conditions  for  the  periodic  tasks 
to  be  schedulable.  There  are  six  inequalities,  one  for  each  task.  Each  inequality  determines 
whether  or  not  a  periodic  task  can  accommodate  its  own  execution  time  (which  includes 
additional  execution  time  caused  by  the  task  dispatcher),  preemption  time  caused  by  all 
higher  priority  tasks,  and  blocking  time  caused  by  the  dispatching  of  all  lower  priority  tasks. 
Note  in  Figure  3-5  that  the  last  inequality  does  not  contain  a  Db  term.  Since  P6  is  the  lowest 
priority  periodic  task,  it  cannot  be  blocked  by  the  dispatching  of  any  lower  priority  periodic 
tasks.  Also  note  that  since  Db=De  in  the  worst  case,12  the  distinction  between  Db  and  De  is 
to  emphasize  that  execution  time  and  blocking  time  are  treated  differently. 


11 Dt  indudes  the  time  that  it  takes  to:  switch  from  the  currently  executing  task  to  the  task  dispatcher, 
determine  which  task(s)  to  activate,  rendezvous  with  the  task(s)  being  activated,  and  switch  back  to  the  highest 
priority  task  ready  to  execute. 

12When  more  than  one  periodic  task  is  activated  at  the  same  time,  higher  priority  tasks  are  activated  first. 
Thus,  when  a  low-priority  task  is  activated  at  the  same  time  as  a  high-priority  task,  Db<De,  because  the  task 
dispatcher  incurs  the  runtime  overhead  associated  with  handling  the  clock  interrupt  only  for  the  first  task  ac¬ 
tivated.  When  a  low-priority  task  is  activated  while  a  high-priority  task  is  already  running,  the  high-priority  task 
will  be  blocked  for  as  long  as  Dt.  Therefore,  Db=Dt  in  the  worst  case. 
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Figure  3-5:  Sufficient  Conditions  for  Periodic  Tasks  to  Be 
Schedulable  in  the  Presence  of  the 

Task  Dispatching  Mechanism 

If  all  of  the  inequalities  of  Figure  3-5  are  satisfied,  then  the  task  set  is  schedulable.  Table 
3-3  contains  a  summary  of  the  various  parameters  that  describe  the  periodic  tasks  and  the 
task  dispatcher.  Substituting  values  from  Table  3-3  into  the  inequalities  of  Figure  3-5,  we 
find  that  all  of  the  inequalities  evaluate  to  true.  Therefore,  the  periodic  tasks  are  still 
schedulable,  even  with  the  overhead  of  the  task  dispatcher  taken  into  account.  Note  that  it 
is  our  intention  to  use  the  INS  to  verify  these  predicted  results  empirically. 


De  =  L 

>6  =  0.2  ms 

Task 

Vi) 

Period 

(T.) 

Exec. 

Figure  3-5  Inequality 
(Leftside)  (Right Side) 

2.56  ms 

0.7  ms 

0.47 

1.00 

P2 

40.96  ms 

5.2  ms 

0.41 

0.82 

P3 

61 .44  ms 

15.2  ms 

0.65 

0.77 

P4 

983.04  ms 

30.2  ms 

0.68 

0.75 

P5 

1 024.0  ms 

50.2  ms 

0.73 

0.74 

P6 

1280.0  ms 

1.2  ms 

0.73 

0.73 

Table 

3-3:  Runtime  Characteristics  of  Periodics  with  the 
Task  Dispatcher 
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While  the  inequalities  shown  in  Figure  3-5  describe  sufficient  conditions  for  the  task  set  to 
be  schedulable,  the  conditions  are  not  necessary.  Therefore,  should  any  one  of  the  in¬ 
equalities  evaluate  to  false,  we  cannot  immediately  conclude  that  the  task  set  is  unschedul- 
able.  Rather,  we  would  proceed  to  apply  the  technique  shown  in  [10]  to  determine  whether 
or  not  a  timeline  exists  such  that  all  of  the  tasks  will  meet  their  deadlines. 

3.2.  Server  Tasks 

In  addition  to  periodicity  requirements,  real-time  systems  often  have  synchronization  re¬ 
quirements  since  (periodic)  tasks  must  interact  to  share  logical  and  physical  resources. 
Task  synchronization  can  be  achieved  in  Ada  by  using  server  tasks.  For  our  purposes,  we 
will  adopt  the  definition  of  an  Ada  server  task  as  presented  in  [16]:  “A  server  task  is  a  task 
whose  accept  statements  are  all  contained  in  a  single  select  statement  that  is  the  only  state¬ 
ment  in  the  body  of  an  endless  loop." 

When  tasks  interact,  priority  inversion  [5]  occurs  if  a  high-priority  task  is  blocked  by  a  lower 
priority  task.  Because  such  a  high-priority  task  must  accommodate  blocking  from  a  lower 
priority  task,  priority  inversion  can  have  a  negative  effect  on  the  overall  schedulability  of  a 
task  set.  Although  priority  inversion  cannot  be  eliminated,  it  can  be  bounded  [1 6]. 

In  this  section  we  will  discuss  some  of  our  relevant  experiences  in  using  Ada  server  tasks  to 
solve  a  typical  data  access  and  consistency  problem.  Our  design  problem  concerns  provid¬ 
ing  a  synchronization  mechanism  by  which  all  six  of  the  INS  periodic  tasks  can  access  a 
shared  table  of  data.  Some  of  the  INS  periodic  tasks  read  this  shared  data,  some  modify  it, 
and  some  do  both.  Since  we  do  not  know  exactly  when  a  task  is  going  to  read  or  write  this 
data  (as  we  would  with  a  cyclic  executive),  the  INS  tasks  must  synchronize  their  access  of 
the  shared  data.  We  will  first  illustrate  how  an  ill-conceived  Ada  tasking  design  for  this  prob¬ 
lem  can  lead  to  uncontrolled  priority  inversion.  Then  we  will  discuss  another  design  alter¬ 
native  which  uses  Ada  tasking  in  a  way  that  will  minimize  the  blocking  time  caused  by  prior¬ 
ity  inversion.  Finally,  we  will  present  some  analytical  techniques  which  are  useful  for  better 
understanding  the  runtime  behavior  of  interacting  tasks. 

3.2.1.  Implementing  Server  Tasks 

In  general,  a  server  task's  entries  correspond  to  the  various  services  that  it  provides  and  we 
consider  a  called  server  task  to  be  executing  on  behalf  of  (or  as  an  extension  to)  its  cor¬ 
responding  client  task.  In  this  section,  we  will  analyze  two  different  task  designs  for  solving 
the  INS  synchronization  problem  introduced  above.  The  first  design  uses  Ada  tasking  to 
implement  a  binary  semaphore  for  protecting  the  shared  data,  whereas  the  second  design 
alternative  implements  an  Ada  server  task  based  on  the  priority  ceiling  protocol  guidelines 
discussed  in  [7, 16]. 

Semaphore  Tasks 

A  binary  semaphore  is  a  widely  accepted  synchronization  primitive  that  can  be  used  for  pro- 
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viding  mutually  exclusive  access  to  a  shared  resource  such  as  the  INS  results  table.  As 
•  illustrated  in  Figure  3-6,  an  Ada  task  can  be  used  to  implement  such  a  binary  semaphore. 

Figure  3-6  also  illustrates  a  possible  implementation  of  a  periodic  client  task  that  uses  this 
semaphore  task  for  gaining  access  to  some  shared  data. 


task  body  Semaphore  la 
begin 
loop 

accapt  Ent«r_Critical_Region; 

accapt  Exit_Critical_Region; 
and  loop; 
and  Semaphore; 

task  body  Pariodic_Cliant  is 
begin 
loop 

accapt  Activate; 

Samaphora .Enter_Critical_Region; 

Do_  Critical  Section_  Read; 

Samapho  ra .  Eacit__Cr  it  ical_Ragion  ; 

Do_Some_Mora_  Work; 
and  loop; 

and  Pariodic_Cliant ; 

Figure  3-6:  Simple  Ada  Binary  Semaphore  Task  and 

a  Periodic  Client  Task 


Unfortunately,  using  a  semaphore  task  for  solving  the  INS  synchronization  problem  can  lead 
to  undesirable  runtime  behavior,  such  as  missed  deadlines.  For  example,  assume  that  the 
•  semaphore  task  in  Figure  3-6  (call  it  S)  controls  access  to  a  block  of  shared  data  that  is 

used  by  all  of  the  INS  periodic  tasks.  In  our  example,  further  assume  that  the  priority  of  S  is 
set  to  be  higher  than  Pv  our  highest  priority  periodic  task,  to  ensure  that  none  of  the  periodic 
client  tasks  can  preempt  S.13  We  will  also  assume  that  each  periodic  task’s  critical  section 
consumes  0.5  ms  of  execution  time.  Under  these  conditions,  our  higher  priority  periodic 
9  tasks  can  be  blocked  by  lower  priority  tasks  for  an  unnecessarily  long  time.  Suppose,  for 

instance,  that  the  phasing  of  all  our  periodic  clients  is  such  that  immediately  after  one  client 
attempts  to  lock  the  semaphore,  the  next  higher  priority  client  becomes  ready  to  execute.  In 
such  a  situation,  the  periodic  clients  will  be  activated  and  thus  make  their  entry  calls  to 
Enter_Critical_Region  in  reverse  priority  order,  i.e.,  a  calling  order  of  P6,  P5,  P4,  Pv  P2,  Pv 
q  and  the  following  could  happen: 

1.P6  is  granted  the  lock  on  the  shared  data  (i.e.,  the  call  by  P6  to 
Enter_Critical_Region  is  accepted)  through  S  at  time  t=0ms. 


13The  priority  of  S  is  set  high,  because  if  it  were  not,  priority  inversion  would  be  possible  if  5  did  not  loop  back 
around  (after  the  Exit_Critical_Region  accept)  prior  to  another  client  call.  Of  course,  this  only  removes  one 
potential  source  of  priority  inversion. 
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2.  Immediately  after  P6  completes  its  rendezvous  with  S  and  enters  its  critical 
section,  P5  preempts  the  critical  section  of  P6  and  attempts  to  lock  the 
resource;  S  is  not  ready  to  accept  another  Enter_Critical_Region  call  since  it 
must  first  accept  a  call  to  Exit_Critical_Region,  so  P5  is  placed  in  the  cor¬ 
responding  entry  queue. 

3.  For  f=4,3, 2,1,  Pi  preempts  the  critical  section  of  P6  immediately  after  the  at¬ 
tempted  rendezvous  of  P1+1  with  S;  P,  is  denied  the  lock  and  is  placed  at  the 
end  of  the  FIFO  entry  queue. 

In  this  example,  the  entry  queue  for  Enter_Critical_Region  will  contain  P{  through  P5  in 
reverse  priority  order.  Sometime  after  time  t=0.5ms  when  P6  completes  its  critical  section, 
the  next  client  task  in  the  entry  queue,  namely  P5,  will  be  granted  access  to  the  resource. 
The  service  requests  will  be  handled  in  FIFO  order  and  consequently  Px  will  have  to  wait  for 
P5  through  P2  to  complete  their  critical  sections  before  it  will  be  granted  the  lock  on  the 
resource.  The  earliest  Px  could  execute  its  critical  section  would  be  sometime  shortly  after 
time  t=2.5ms  since  it  would  be  blocked  for  a  total  of  2.5  ms  waiting  for  the  other  periodic 
clients  to  complete  their  critical  sections.  Clearly,  with  a  period  of  2.56  ms  and  0.70  ms  of 
compute  time  (see  Table  3-3),  Px  will  miss  its  first  deadline  as  a  result  of  this  blocking  time 
caused  by  this  tasking  design. 

The  blocking  time  of  Px  could  be  even  longer  if  we  introduce  another  periodic  task,  Pww,  that 
does  not  use  S  and  whose  priority  is  between  that  of  Pj  and  P2.  Assuming  that  the  execution 
time  of  PMW  is  3  ms  and  the  same  phasing  exists  for  this  new  task  set,  Px  will  be  blocked  an 
additional  3  ms  because  of  the  execution  of  P^.  The  three  steps  discussed  above  still 
apply,  but  now  PMW  will  preempt  P6,  and  thus,  P6  will  not  complete  its  critical  section  until 
shortly  after  time  t=3.5ms.  Consequently,  the  earliest  that  P,  can  now  execute  its  critical 
section  would  be  sometime  shortly  after  time  t=5.5ms,  since  it  is  being  blocked  by  P^  for 
an  additional  3  ms. 

On  the  surface  our  semaphore  (synchronization)  task,  S,  looks  innocuous.  But  as  we  have 
illustrated,  this  type  of  design  can  lead  to  arbitrarily  long  blocking  time  and  undesirable  run¬ 
time  behavior.  The  next  subsection  discusses  a  design  approach  that  bounds  and  min¬ 
imizes  this  blocking  time  caused  by  priority  inversion. 

Server  Tasks  That  Emulate  the  Priority  Celling  Protocol 

The  essence  of  our  second  design  approach  for  solving  the  INS  synchronization  problem  is 
to  use  Ada  server  tasks  to  model  semaphores  as  discussed  in  [16],  and,  further,  to  design 
and  implement  these  server  tasks  so  that  their  runtime  behavior  emulates  the  priority  ceiling 
protocol  (PCP)14  [7, 16].  The  PCP  guarantees  that: 

1 .  The  execution  of  a  high-priority  client  task  can  be  delayed  by  at  most  one 
lower  priority  client  task  per  server  call. 


14PCP  emulation  is  necessary  for  the  cases  in  which  the  runtime  system  does  not  implement  the  protocol 
directly. 
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2.  A  deadlock  cannot  occur  as  long  as  a  task  does  not  call  itself. 

3.  Blocked  calls  to  the  same  server  task  are  serviced  in  order  of  priority  [1 6]. 

For  convenience,  we  will  denote  these  properties  as  PCP1,  PCP2,  and  PCP3. 


'task  body  Sarvar  is 

begin 

loop 

select 

accept  Service  1  do 

Periorm_  Service_  1; 

--  Critical  region  # 1 

and  Service_l; 

or 

accept  Service  2  do 

Perform_Service_2; 

-  Critical  region  #2 

end  Service_2; 

or 

accept  Service  n  do 

Pariorm_Service_n; 

-  Critical  region  ttn 

end  Service  n; 

end  select; 

and  loop; 

end  Server; 

Figure  3-7:  General  Structure  of  an  Ada  Server  Task 

Figure  3-7  illustrates  the  canonical  form  of  a  priority  ceiling  server  task  written  in  Ada. 
Notice  the  difference  between  the  semaphore  task  of  Figure  3-6  and  the  server  task  of 
Figure  3-7.  In  the  latter  model,  the  critical  section  code  is  within  the  accept  body  for  each 
respective  service  and  not  within  the  client’s  body. 

The  priority  ceiling  of  a  server  task  is  defined  as  the  highest  priority  of  its  client  tasks,  i.e., 
the  highest  priority  of  tasks  that  can  call  the  server  directly  or  indirectly.  To  properly  emulate 
the  priority  ceiling  protocol,  our  approach  must  guarantee  that  the  following  condition  always 
holds: 

Any  entry  call  from  a  client  task  T  to  a  server  task  5  can  be  accepted  if  and  only  if 
the  priority  of  T  is  higher  than  the  highest  priority  ceiling  of  all  other  servers  ex¬ 
ecuting  on  behalf  on  clients  other  than  T  [1 6]. 
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By  following  the  rules  listed  below,  one  can  emulate  the  PCP  protocol  in  Ada  applications:15 

1 .  Set  the  priority  of  server  tasks  to  be  equal  to  their  priority  ceiling  plus  1  by 
using  pragma  PRIORITY.16 

2.  Implement  server  tasks  using  the  structure  shown  in  Figure  3-7. 

Rule  1  guarantees  that  all  client  requests  are  serviced  without  the  possibility  of  being 
preempted  by  any  other  of  the  server's  clients.  Consequently,  once  a  client  enters  the  ren¬ 
dezvous  with  the  server,  that  task  will  be  the  highest  priority  client  eligible  to  execute;  thus, 
no  other  client  can  make  a  call  to  that  server.  This  runtime  behavior  also  guarantees  that  no 
clients  will  be  blocked  on  a  server  call,  so  property  PCP3  is  always  preserved.  Rule  2  im¬ 
poses  a  task  coding  style  which  yields  a  structure  that  models  the  notion  of  critical  regions 
guarded  by  a  semaphore,  thus  allowing  us  to  apply  real-time  scheduling  theory  based  on 
semaphores  to  our  system  of  Ada  tasks  [7, 1 6]. 

Assuming  non-suspending  server  tasks,  following  Rules  1  and  2  in  the  context  of  Ada’s 
scheduling  rules  will  ensure  that  the  fundamental  condition  of  PCP  stated  above  is  always 
met17  For  example,  suppose  we  have  three  client  tasks  (from  highest  to  lowest  priority:  Pv 
P2,  P3)  and  two  server  tasks  {Sv  SJ.  Assume  P1  calls  S,  and  P2  and  P3  call  S2.  Rule  1 
implies  the  following  priority  ordering:  Sv  Pv  S2,  P2,  Pv  Notice  that  since  the  priority  of  Px  is 
greater  than  the  priority  ceiling  of  S2,  the  priority  of  Px  is  higher  than  the  priority  of  S2.  Sup¬ 
pose  that  S2  is  executing  on  behalf  of  P3  and  then  Px  and  P2  both  become  ready  to  run.  In 
this  case,  Px  will  preempt  the  execution  of  S2  and  be  able  to  complete  all  of  its  execution, 
including  its  call  to  Sy  Under  these  circumstances,  as  would  be  the  case  for  an  actual  PCP 
runtime,  Px  can  preempt  the  execution  of  S2  because  its  priority  is  higher  than  the  highest 
priority  ceiling  of  all  other  servers  (i.e.,  S2)  executing  on  behalf  of  clients  (i.e.,  P3)  other  than 
Pv  After  P j  completes  its  execution,  s2  will  resume  its  execution  on  behalf  of  client  Py  As 
soon  as  this  service  has  completed,  P2  will  begin  executing  by  preempting  Pv  showing  how 
our  Rule  1  works  in  enforcing  property  PCP1 .  Finally,  knowing  that  the  underlying  condition 
of  the  PCP  is  upheld  by  following  our  guidelines,  it  follows  that  property  PCP2  must  also 
hold. 


15Assuming  that  the  server  task(s)  do  not  execute  any  statements  which  would  cause  them  to  suspend  (e.g., 
synchronous  I/O  operation). 

16ln  practice,  Ada  implementations  vary  with  respect  to  their  scheduling  behavior  for  tasks  with  equal  priority. 
Therefore,  to  ensure  that  runtime  behavior  is  consistent  with  the  expectations  of  rate-monotonic  theory  across 
differing  Ada  implementations,  server  tasks  should  be  assigned  priorities  which  do  not  conflict  with  other  client 
tasks’  priorities.  Because  the  server’s  priority  must  be  at  least  that  of  its  highest  priority  client  TH,  we  recom¬ 
mend  assigning  the  server  task  a  priority  one  larger  than  the  priority  of  TH. 

17A  third  rule  could  be  added  for  dealing  with  server  tasks  which  suspend:  implement  a  prioritized  server  task; 
i.e.,  a  server  task  that  sen/ices  client  requests  based  on  their  assigned  priority  rather  than  in  FIFO  order.  Since 
the  server  tasks  can  potentially  suspend  during  a  service  call,  resulting  in  client  service  requests  queuing  in  their 
order  of  arrival,  prioritized  entry  queues  are  necessary.  There  are  numerous  approaches  to  implementing  a 
prioritized  server  in  Ada  using  server  tasks  with  entry  families  (3, 6].  Unfortunately,  this  approach  will  not 
emulate  the  PCP  for  all  task  sets.  In  particular,  in  the  presence  of  nested  server  calls  it  is  possible  to  get  a 
deadlock  using  this  approach. 
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Let’s  now  reexamine  the  INS  synchronization  problem.  For  the  sake  of  the  example,  as¬ 
sume  that  the  periodic  client  tasks  either  read  or  write  the  shared  data  during  their  respec¬ 
tive  critical  sections.  Assuming  that  the  access  to  the  shared  data  cannot  cause  any  task 
suspension,  we  want  to  construct  a  PCP  server  task  which  will  service  both  read  and  write 
requests  from  the  periodic  clients  using  the  guidelines  outlined  above.  As  before,  we  will  set 
the  server’s  priority  to  be  higher  than  the  priority  of  P{,  in  particular,  we  will  set  its  priority  to  1 
more  than  the  priority  of  Px  (Rule  1 ).  We  can  construct  a  PCP  server  task  and  correspond¬ 
ing  periodic  client  as  illustrated  in  Figure  3-8  (Rule  2).  Notice  that  this  server  task  is  really  a 
monitor  that  protects  the  shared  Results_Table  defined  in  the  task  body. 


task  body  Raaulta_Tabla_Monitor  is 
Raaulta_Tabla  :  Rasul ts_Tabla_Typ«; 
bag  in 
loop 

salaet 

accapt  Road_Sarvica  (...)  do 
Do_  Critical f_  Section_  Read; 
and  Raad_Sarvica; 
or 

aaoapt  Writa_Sarvioa  (...)  do 
Do_Cr'itical_Section_  Writs; 
and  Hrita_Sarviea; 
and  salaet; 
and  loop; 

and  Rasults_Tabla_Monitor; 

task  body  Pariodie_Cliont  is 
bag  in 
loop 

accapt  Activate; 

Rasulta_Tabla_Monitor . Raad_Sarvica (...); 
Do_Some_More_  Work; 

and  loop; 

and  Pariodio_Cliant; 

Figure  3-8:  PCP  Server  Task  and 
a  Periodic  Client  Task 


The  runtime  behavior  of  our  task  set  example  will  now  change  when  compared  with  the 
semaphore  task  of  the  previous  section.  Assuming  the  original  INS  task  set  without  P^,  P6 
will  still  be  granted  the  lock  at  time  t=0ms.  However,  the  other  periodics — although  they  will 
have  become  ready  to  execute  while  P6  is  executing  its  critical  section — will  not  run,  since 
the  Results_Table_Monitor  task  has  higher  priority.  P6  will  complete  its  critical  section  at 
time  t=0.5ms  as  before  and  P5  through  P1  will  be  ready  to  run.  Shortly  after  time  t=0.5ms, 
the  next  highest  priority,  ready  to  run  task,  namely  Pv  will  execute  (remember,  using  the 
tasking  structure  of  Figure  3-6,  Px  did  not  execute  until  after  time  t=2.5ms).  In  this  case,  Px 
can  meet  its  first  deadline  at  r=2.56;  previously  it  could  not. 
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Analyzing  the  INS  task  set  including  p ^  shows  that  the  above  runtime  behavior  with 
respect  to  the  effects  of  blocking  on  Px  still  applies.  Px  will  start  executing  its  critical  section 
sometime  after  time  t =0.5  ms.  PMW  is  assumed  to  be  ready  to  run  prior  to  time  r=0.5ms 
based  on  our  phasing,  but  it  will  be  blocked  by  the  Results_Tab!e_Monitor  executing  on 
behalf  of  P6. 

As  these  two  examples  illustrate,  using  the  PCP  emulation  approach,  the  INS  client  tasks  in 
our  example  will  start  their  execution  in  priority  rather  than  FIFO  order,  thereby  minimizing 
the  blocking  time  caused  by  priority  inversion  caused  by  task  synchronization.  Furthermore, 
this  approach  reduces  the  number  of  rendezvous  (from  two  to  one)  for  accomplishing  task 
synchronization  in  comparison  with  the  Semaphore  task  model. 

3.2.2.  Analyzing  the  Schedulability  Effects  of  Server  Tasks 

The  previous  section  presented  specific  guidelines  for  constructing  server  tasks  in  Ada  such 
that  the  properties  of  the  priority  ceiling  protocol  would  be  preserved.  This  section  presents 
analytical  techniques  that  may  be  used  to  understand  and  predict  the  behavior  of  systems  in 
which  periodic  and  server  tasks  interact. 

We  will  begin  by  demonstrating  techniques  for  analyzing  the  effect  of  server  tasks  on  the 
schedulability  of  a  task  set.  Then  we  will  briefly  discuss  the  additional  complexity  associated 
with  analyzing  the  effects  of  server  tasks  which  may  suspend  themselves. 

Including  Blocking  Time  In  the  Analysis 

Server  tasks  introduce  blocking  time.  To  analyze  the  effect  of  server  tasks  on 
schedulability,  the  analytical  techniques  must  be  able  to  treat  blocking  time  as  well  as  ex¬ 
ecution  time.  General  analytical  techniques  that  treat  both  blocking  time  and  execution  time 
are  available.  In  this  section,  we  will  apply  the  generalized  techniques  to  the  case  in  the  INS 
where  the  six  periodic  tasks  obtain  mutually  exclusive  access  to  shared  data  through  the 
Results_Table_Monitor  server.  Furthermore,  we  will  build  on  our  earlier  analysis  of  the  task 
dispatcher  overhead. 

When  we  apply  the  techniques  of  [1 6]  to  the  problem  of  determining  whether  or  not  the  six 
periodic  tasks  in  the  INS  task  set  are  schedulable  in  the  presence  of  the 
Results_Table_Monitor  server,  we  end  up  with  the  series  of  inequalities  shown  in  Figure 
3-9.  The  inequalities  express  sufficient  conditions  for  the  periodic  tasks  to  be  schedulable. 
There  are  six  inequalities,  one  for  each  periodic  task.  Each  inequality  is  to  determine 
whether  or  not  a  periodic  task  can  accommodate  its  own  execution  time,  preemption  time 
caused  by  all  higher  priority  periodic  tasks,  and  blocking  time  due  to  all  lower  priority  tasks. 
We  assume  that  each  C,  includes  the  execution  time  of  the  server  on  behalf  of  the  periodic 
client.  In  each  inequality  except  the  last  one,  a  Bx  term  represents  the  worst-case  blocking 
time  for  Pi  due  to  lower  priority  tasks  using  the  server.  Since  P6  is  the  lowest  priority  periodic 
task,  it  cannot  be  blocked  by  a  lower  priority  periodic  task.  For  the  periodic  tasks  to  be 
schedulable,  all  of  the  inequalities  shown  in  Figure  3-9  must  be  satisfied. 
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To  evaluate  the  inequalities,  we  must  determine  the  value  of  each  Bi  in  the  equation.  P5  can 
be  blocked  when  the  server  is  executing  on  behalf  of  P6  and  when  the  task  dispatcher  ac¬ 
tivates  P6.  Thus,  if  S-  represents  the  execution  time  of  the  Results_Table_Monitor  server  on 
behalf  of  periodic  client  Pit  then  fl5=S6.  Note  that  the  blocking  time  caused  by  the  task  dis¬ 
patcher  has  already  been  accounted  for  in  the  inequalities.  /%  can  be  blocked  when  the 
server  is  executing  on  behalf  of  P5  or  P6  and  when  the  task  dispatcher  is  activating  P5  and 
P6.  Therefore,  B4= max (S5,SJ.  Values  for  Bv  Bv  and  Bx  can  be  determined  in  the  same 
manner. 


Table  3-4  contains  a  summary  of  the  various  parameters  that  describe  the  periodic  tasks 
and  the  Results_Table_Monitor  server.  Substituting  values  from  Table  3-4  into  the  in¬ 
equalities  of  Figure  3-9,  we  find  that  all  of  the  inequalities  evaluate  to  true.  Therefore,  the 
periodic  tasks  are  still  schedulable  even  in  the  presence  of  the  blocking  time  introduced  by 
the  Results_Table_Monitor  server.  Had  any  one  of  the  inequalities  evaluated  to  false,  we 
would  not  have  concluded  that  the  task  set  was  unschedulable.  Then  we  would  have 
proceeded  to  apply  the  technique  shown  in  [10]  that  uses  numerical  methods  to  determine 
whether  a  timeline  exists  such  that  all  of  the  tasks  will  meet  their  deadlines. 
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De  =  Db  =  0.2  ms 


Task  Period  Exec.  Server  Block  Figure  3-9  Inequality 


( T ,) 

(Ci+Dt) 

(S,> 

(*i) 

(Left  Side) 

(Right  Side) 

**1 

2.56  ms 

0.7  ms 

0.45  ms 

0.60  ms 

0.70 

1.00 

pz 

40.96  ms 

5.2  ms 

0.60  ms 

0.52  ms 

0.42 

0.82 

P3 

61.44  ms 

15.2  ms 

0.52  ms 

0.44  ms 

0.66 

0.77 

P4 

983.04  ms 

30.2  ms 

0.44  ms 

0.34  ms 

0.68 

0.75 

P5 

1 024.0  ms 

50.2  ms 

0.25  ms 

0.34  ms 

0.73 

0.74 

P6 

1280.0  ms 

1.0  ms 

0.34  ms 

0.00  ms 

0.73 

0.73 

Table  3-4:  Runtime  Characteristics  of  Periodic  Tasks 
Including  Task  Dispatcher  and 
Results_Table  Monitor  Server 


Note  that  the  following  inequality  is  a  sufficient  condition  for  all  of  the  inequalities  shown  in 
Figure  3-9  to  be  true  [16]: 


C,  C,  Cfi 

_+_+  ...  +_+  max  ( 


(Bi+SDJ  (52+40^)  (S3  +  3-D^)  (B4+2DJ  (S5+ !£>*,) 


)<6(21/6-l) 


1 1  1 2  1 1  1 2  l3  *  4  *5 

Thus,  the  inequality  above  could  have  been  used  as  a  quick  test  before  applying  the  in¬ 
equalities  in  Figure  3-9.  Had  the  quick  test  evaluated  to  true,  then  the  six  inequalities  in 
Figure  3-9  would  also  have  been  true.  But  if  the  quick  test  had  failed,  then  the  six  in¬ 
equalities  in  Figure  3-9  would  have  to  have  been  evaluated  in  turn.  In  other  words,  the 
single  inequality  above  is  a  sufficient  condition  for  the  inequalities  in  Figure  3-9  to  be  satis¬ 
fied,  but  it  is  not  a  necessary  condition.  The  purpose  of  the  single  inequality  is  to  try  to  save 
time  when  testing  for  schedulability. 


Illustrating  an  Effect  of  Task  Suspension 

There  are  many  cases  in  which  a  server  task  may  suspend.  For  example,  tasks  Pj  and  P4  in 
the  INS  task  set  send  messages  to  an  external  computer  system  (ECS).  Message  sending 
services  that  ensure  mutually  exclusive  access  to  the  communications  port  are  provided  by 
a  server  called  the  Communications_Controller.  Since  the  communications  protocol  be¬ 
tween  the  INS  and  the  ECS  involves  handshaking  and  the  I/O  is  interrupt-driven,  the 
Communications_Controller  must  suspend  routinely  while  waiting  to  hear  back  from  the 
ECS.18 


Rate-monotonic  scheduling  theory  assumes  that  a  task  which  is  eligible  to  run  will  indeed 
execute  on  the  CPU  until  either  the  task  completes  its  designated  duty  or  the  task  is 


18Nominal  message  transmission  sequence  is  as  follows:  (1)  INS  sends  start-of-message  to  ECS,  (2)  ECS 
replies  by  returning  ready-to-receive  to  INS,  (3)  INS  sends  packet  of  data  words  followed  by  end-of-message  to 
ECS,  (4)  ECS  validates  the  data  packet  and  sends  acknowledgement  back  to  the  INS. 


preempted  by  a  higher  priority  task  which  is  also  eligible  to  run.  In  the  case  described  ear¬ 
lier,  synchronous  I/O  with  the  ECS  leads  to  a  violation  of  this  basic  assumption  since  the 
Communications_Control!er  gives  up  the  CPU  before  completing  its  designated  duty.  In 
general,  when  a  periodic  task  (or  a  server  task  executing  on  behalf  of  a  periodic  client) 
suspends  in  this  manner,  we  refer  to  the  period  of  time  that  the  task  is  suspended  as  idle 
time. 

When  analyzing  the  schedulability  of  a  periodic  task  that  may  suspend,  idle  time  must  be 
accounted  for  in  the  same  manner  as  execution  time,  even  though  the  task  that  suspends 
does  not  use  the  CPU  during  the  idle  time.  Thus,  the  Ci  term  for  the  task  should  include 
both  execution  time  and  idle  time.  But  the  analytic  treatment  of  idle  time  does  not  stop 
there.  Idle  time  may  also  have  an  adverse  effect  on  lower  priority  tasks.  This  adverse  effect 
is  counter-intuitive  since  it  would  seem  that  lower  priority  tasks  should  be  able  to  take  ad¬ 
vantage  of  a  higher  priority  task’s  idle  time.  We  will  illustrate  this  adverse  effect  by  way  of 
an  example. 

Consider  the  three  periodic  tasks  shown  in  Figure  3-1  Oa.  The  three  tasks  are  schedulable 
for  all  possible  phasings,  given  their  execution  times  and  periods.19  This  particular  phasing 
is  used  because  it  will  point  out  the  effect  of  idle  time  on  lower  priority  tasks.  In  Figure 
3-1  Oa,  none  of  the  tasks  can  suspend.  Note  that  P2  requires  3  units  of  execution  time  and 
that  P3  finishes  well  before  its  deadline  at  time  r=  28.  Now  we  will  introduce  idle  time  and  try 
to  predict  the  results.  Let  us  hypothesize  that  P2  still  requires  just  3  units  of  execution  time, 
but  that  it  exhibits  the  following  runtime  behavior:  P2  executes  for  2  units,  suspends  for  1 
unit,  and  then  executes  for  1  more  unit.  Our  intuition  is  that  the  three  tasks  should  still  be 
schedulable.  After  all,  we  have  not  increased  C2;  we  have  only  deferred  part  of  it  until  later 
in  T2.  Our  intuition  also  suggests  that  P2  will  complete  later  in  J2  than  it  had  before  and  that 
P3  will  complete  sooner  in  r3  than  it  had  before.  Without  idle  time,  P3  had  to  wait  until  both 
P{  and  P2  had  finished  before  it  could  use  the  CPU.  With  idle  time,  P3  has  to  wait  only  until 
P,  finishes  and  P2  executes  two  units  before  it  can  use  the  CPU. 


19To  verify  this  claim,  draw  a  timeline  in  which  all  three  tasks  are  activated  at  the  same  time  i  timeline  will 
show  that  all  three  tasks  will  meet  their  first  deadlines.  Therefore,  they  will  meet  all  of  their  deadline  ;  1 2]. 
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Figure  3-1  Ob  illustrates  the  effect  of  the  idle  time  of  P2  on  Pv  Obviously,  our  intuition  was 
wrong.  Not  only  does  P3  fail  to  finish  early,  it  fails  to  meet  its  deadline  at  time  r =28;  the  three 
tasks  are  no  'onger  schedulable.  Essentially,  P3  is  penalized  because  part  of  C2  is  deferred 
until  later  in  72.  This  effect  is  known  as  the  deferred  execution  penalty  [  11, 15].  In  our  ex¬ 
ample,  this  can  be  seen  by  observing  in  Figures  3-1  Oa  and  3-1  Ob  that  r3  is  24  units  long  and 
that  one  of  the  three  tasks  is  executing  during  each  of  the  24  units.  In  Figure  3-1  Oa,  />, 
executes  for  5  of  the  24  units,  P2  executes  for  12  of  the  24  units,  and  P3  executes  for  7  of  the 
24  units.  In  Figure  3-1  Ob,  P,  still  executes  for  5  of  the  24  units  but  P2  executes  for  13  of  the 
24  units,  leaving  only  the  remaining  6  units  for  Pv 

The  complete  effect  of  idle  time  on  the  scheduiability  of  a  task  set  is  not  yet  fully  understood. 
Therefore,  only  pessimistic  worst-case  scheduiability  bounds  are  available  [15].  A  complete 
understanding  of  the  effects  of  idle  time  is  very  important  in  order  for  the  scheduling  theory 
to  be  generally  applicable. 

The  problems  associated  with  idle  time,  while  not  new,  have  been  brought  to  the  forefront  by 
our  work  on  the  INS.  In  fact,  one  of  the  main  objectives  of  the  INS  development  was  to 
expose  problem  areas  for  which  treatment  was  lacking  or  ad  hoc.  The  SEI  REST  and 
RTSIA  projects  and  CMU  ART  project  will  collectively  address  the  idle  time  problem  in  the 
near  term. 


3.3.  Aperiodic  Tasks 

Many  real-time  systems  are  driven  by  the  need  to  respond  to  aperiodic  events.  Consid¬ 
erable  theoretical  work  has  been  done  in  this  area  [1 1].  This  work  provides  a  conceptual 
framework  for  analyzing  the  scheduiability  of  a  system  with  aperiodic  processing  require¬ 
ments.  However,  many  questions  remain  unanswered  regarding  the  construction  of  analyz- 
able  models  for  handling  aperiodic  tasks  in  Ada.  This  section  summarizes  several  important 
concepts  for  understanding  how  to  incorporate  aperiodicity  into  a  scheduiability  model. 

Server  tasks  execute  only  on  behalf  of  other  tasks.  Periodic  tasks  are  tasks  with  a  periodic 
timing  requirement  that  execute  on  their  own  behalf.  Aperiodic  tasks  also  execute  on  their 
own  behalf,  but  do  not  have  periodic  timing  requirements;  however  they  may  have  response 
time  requirements.  Typically,  aperiodic  tasks  execute  in  response  to  an  event  or  perform  a 
low-priority  background  function. 

Given  a  set  of  periodic  tasks  and  a  response  time  requirement  for  an  aperiodic  task,  we 
must  ensure  that  aperiodic  response  time  requirements  are  met,  and  at  the  same  time,  un¬ 
derstand  the  effect  of  aperiodic  tasks  on  the  scheduiability  of  the  remainder  of  the  task  set. 
The  concept  of  an  aperiodic  execution  manager  [11],  also  called  an  aperiodic  server,  helps 
to  address  both  of  these  issues.  An  aperiodic  execution  manager  is  conceptually  a  periodic 
task20  that  doles  out  execution  time  to  aperiodic  tasks.  This  allows  aperiodic  utilization  to  be 


^An  aperiodic  execution  manager  may  manifest  itself  as  an  Ada  task  or  an  algorithm  in  the  runtime  system. 
From  the  point  of  view  of  the  scheduiability  analysis,  it  is  viewed  as  a  periodic  task. 
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analyzed  in  a  periodic  framework,  assuming  that  there  is  a  known,  minimum  separation  of 
aperiodic  events.  See  [11, 18,  19]  for  a  discussion  of  the  various  strategies  for  managing 
aperiodic  execution.  Given  this  conceptual  framework,  let  us  address  three  types  of 
aperiodic  tasks: 

•  An  aperiodic  task  that  has  a  hard  deadline  for  its  response  to  an  event. 

•  An  aperiodic  task  that  has  either  a  soft  deadline  or  no  deadline  for  its  response 
to  an  event. 

•  An  interrupt  handler,  which  executes  at  a  very  high  priority  regardless  of  its  re¬ 
sponse  time  requirement. 

The  basic  strategy  for  meeting  a  hard  deadline  requirement  is  to  give  the  aperiodic  execu¬ 
tion  manager  (that  serves  such  a  task)  a  high  enough  priority.  Clearly,  if  the  manager  has 
the  highest  execution  priority  in  the  system  (assuming  that  there  are  no  interrupts)  then  the 
aperiodic  task  will  meet  its  deadline  if  its  execution  time  is  less  than  its  response  time.  To 
analyze  the  schedulability  of  the  entire  system,  the  aperiodic  execution  manager  is  factored 
in  as  one  of  the  periodic  tasks.  Preserving  schedulability  of  the  periodics  may  not  permit  the 
aperiodic  manager  to  execute  at  the  highest  priority  in  the  system.  Thus,  part  of  the 
schedulability  analysis  of  a  system  of  tasks  that  has  both  periodics  and  aperiodics  will  in¬ 
volve  determining  a  priority  for  the  aperiodic  manager  that  meets  the  response  time  require¬ 
ment  and  still  allows  the  periodic  tasks  to  meet  their  deadlines.  If  this  is  impossible,  the 
requirements  are  untenable;  the  requirements  must  be  relaxed  or  a  system  overload  could 
occur.  If  it  is  possible,  then  periodic  deadlines  and  response  time  requirements  are 
guaranteed.  In  both  cases  we  have  predictable  results. 

If  an  aperiodic  task  does  not  have  a  hard  deadline  but  it  is  still  advantageous  to  service 
aperiodic  activity  in  a  timely  fashion,  the  aperiodic  execution  manager  is  still  a  viable  ap¬ 
proach.  The  philosophy  in  this  case  is  slightly  different.  For  aperiodic  tasks  with  hard  dead¬ 
lines,  one  may  be  willing  to  sacrifice  low-priority  periodic  deadlines.  However,  in  the  ab¬ 
sence  of  a  hard  deadline,  the  goal  is  to  take  advantage  of  spare  CPU  capacity  in  a  manner 
that  is  advantageous  to  aperiodic  tasks.  Using  the  same  strategy  described  above,  the  aim 
is  to  find  the  highest  priority  level  in  the  rate-monotonic  pecking  order  that  achieves  all  peri¬ 
odic  deadlines  and  minimizes  aperiodic  response  time. 

The  first  two  cases  required  that  we  find  a  suitable  priority  for  the  aperiodic  manager.  How¬ 
ever,  interrupts  are  handled  at  a  priority  higher  than  all  Ada  task  priorities;  thus,  a  high  prior¬ 
ity  is  imposed  on  this  type  of  aperiodic  processing  independent  of  its  response  time  require¬ 
ment.  The  approach  for  analyzing  this  case  is  slightly  different.  Once  again  we  assume  that 
aperiodic  interrupts  are  separated  by  a  minimum  time  interval.  In  the  worst  case,  interrupts 
occur  periodically,  with  that  minimum  separation  interval  as  the  period.  There  is  a  rate- 
monotonic  priority  associated  with  this  period.  For  all  tasks  with  a  priority  higher  than  this 
priority,  the  interrupt  execution  is  treated  as  blocking  time.  For  all  lower  priority  tasks,  this 
interrupt  is  treated  as  a  higher  priority  periodic  task.  Assuming  that  this  interrupt  is  neither 
masked  nor  interrupted,  response  time  is  not  an  issue  in  this  case. 
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3.4.  Recommendations 


Recent  scrutiny  of  Ada  oy  the  real-time  software  community  has  identified  inadequacies  in 
the  language  with  respect  to  expressing  and  handling  real-time  behavior  [4,  5,  6, 13, 14]. 
These  identified  limitations  include:  nondeterministic  selection  of  open  alternatives,  FIFO 
entry  call  queues,  lack  of  an  adequate  time  abstraction  for  implementing  real-time  require¬ 
ments,  and  problems  with  using  the  delay  statement  to  achieve  periodic  processing.  In  this 
section,  we  offer  several  guidelines  for  engineering  real-time  systems  in  Ada  based  on  our 
own  experiences  with  the  INS  application.  These  guidelines  are  intended  to  demonstrate 
how  to  design  Ada  real-time  systems  in  ways  that  circumvent  the  problems  mentioned 
above  and  enhance  the  predictability  of  runtime  behavior.  Our  recommendations  for  man¬ 
aging  concurrency  in  Ada  are  summarized  below. 

1.  Design  and  Implement  analyzable  software  systems.  To  fully  understand 
and  be  able  to  reliably  predict  the  runtime  behavior  of  a  real-time  Ada  appli¬ 
cation,  you  must  design  and  implement  your  system  in  a  manner  which  is 
amenable  to  the  application  of  real-time  scheduling  theory.  Generally,  this 
means  that  you  should  design  and  implement  your  application  by  using  lan¬ 
guage  features  in  well  understood  and  analyzable  ways.  Without  this  type  of 
engineering  approach,  there  are  no  guarantees  regarding  the  execution  timing 
behavior  of  your  real-time  Ada  application. 

2.  Understand  how  to  Implement  analyzable  periodicity.  Implementing 
analyzable  periodicity  depends  on  task  priority  assignment  and  the  design  par¬ 
adigm  used  for  achieving  periodic  processing.  The  RMA  should  be  used  as  a 
basis  for  task  priority  assignment,  since  it  is  an  optimal  fixed  priority  algorithm, 
because  a  solid  body  of  scheduling  theory  is  based  on  this  algorithm,  and  be¬ 
cause  it  is  applicable  to  Ada.  We  recommend  the  DelayJJntil  model  for 
achieving  periodicity,  provided  that  the  runtime  system’s  timing  resolution 
meets  the  application's  requirements.  If  the  functionality  that  is  needed  to 
support  the  DelayJJntil  model  is  not  available  or  does  not  provide  the  required 
timing  resolution,  the  Dispatcher  model  is  a  suitable  alternative. 

Also,  be  aware  of  effects  that  can  alter  periodicity.  For  the  DelayJJntil  and 
Dispatcher  models,  it  is  very  important  to  understand  the  system’s  interrupt 
structure.  In  particular  it  is  important  to  know  if,  when,  and  for  how  long  the 
underlying  real-time  clock’s  interrupt  is  masked.  If  models  other  than  these  two 
are  used  (for  example,  using  the  delay  statement  in  the  manner  suggested  in 
section  9.6  of  the  LRM),  then  awareness  of  the  potential  for  delay  jitter  is  im¬ 
portant. 

3.  Minimize  priority  inversion  by  using  the  priority  ceiling  protocol.  Be 
aware  of  priority  inversions  that  may  be  caused  by  task  interactions.  Since 
high-priority,  high-frequency  tasks  must  be  able  to  accommodate  additional 
blocking  time  that  results  from  priority  inversions,  the  overall  schedulability  of  a 
task  set  can  be  greatly  affected  by  task  interactions.  While  the  priority  inver¬ 
sions  cannot  be  completely  eliminated,  they  can  be  minimized  by  creating  ser¬ 
ver  tasks  that  emulate  the  priority  ceiling  protocol  (assuming,  of  course,  that 
the  runtime  system  does  not  directly  support  the  priority  ceiling  protocol). 

4.  Understand  the  Interactions  between  your  application  and  the  Ada  run* 
time  system.  In  order  to  perform  a  comprehensive  schedulability  analysis  of 
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your  application,  its  interaction  with  the  Ada  runtime  system  needs  to  be  well 
understood.  Generally,  this  "’eans  that  you  should  identify  all  potential 
sources  of  execution  time,  preemption  time,  and  blocking  time  in  both  your 
application  and  the  Ada  runtime  system.  In  particular,  be  aware  of  the  effects 
of  context  switching  and  idle  time. 
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4.  Conclusion 

Experimenting  with  design  and  implementation  alternatives  in  the  context  of  an  actual  real¬ 
time  application  (the  INS)  has  led  us  to  several  conclusions  concerning  the  development  of 
real-time  systems  in  Ada: 

•  Ada  allows  the  real-time  programmer  to  handle  devices  and  concurrency  at  a 
relatively  high  level  of  abstraction;  however,  these  language  features  do  not 
relieve  the  programmer  of  low-level  data  representation  concerns  and 
schedulability  concerns. 

•  Applying  analytical  methods  in  concert  with  experimentation  and  prototyping 
can  provide  important  insights  about  the  system’s  runtime  behavior  throughout 
the  life  cycle  of  a  real-time  system. 

•  Given  analytical  methods  and  coding  guidelines,  Ada  has  the  potential  to  be 
successfully  used  in  real-time  systems. 

The  Ada  language  has  specific  features  that  address  the  need  to  control  devices  and  man¬ 
age  concurrency.  Representation  specifications  allow  the  programmer  to  interact  with  a  de¬ 
vice  by  using  record  types  to  model  the  memory  map  of  its  registers.  However,  the  respon¬ 
sibility  for  ensuring  proper  data  representation  is  still  in  the  hands  of  the  programmer.  Com¬ 
piler  optimization  may  thwart  attempts  to  control  a  device  by  eliminating  important  steps  in  a 
sequence  of  device  control  instructions.  Awareness  of  the  relationship  between  the  bit  and 
byte  numbering  schemes  of  the  underlying  hardware  and  the  model  used  by  the  Ada  imple¬ 
mentation  is  also  important. 

Ada  tasking  provides  a  conceptual  model  for  managing  concurrency.  This  model  allows 
implementation  of  concurrency  at  a  relatively  high  level  of  abstraction.  However,  raising  the 
level  of  abstraction  for  real-time  programming  is  beneficial  only  if  the  resulting  behavior  is 
predictable.  Using  tasking  in  a  manner  that  results  in  predictable  runtime  behavior  requires 
careful  analysis.  The  analytical  methods  presented  in  this  report  offer  a  framework  for  per¬ 
forming  such  an  analysis. 

Early  exploration  of  high  risk  areas  such  as  device  interfaces  and  system  timing  behavior 
exposes  problem  areas  early:  uncovering  inconsistent  or  unreasonable  requirements,  de¬ 
tecting  potential  performance  problems,  and  making  hardware/software  tradeoffs.  Continual 
iteration  through  cycles  of  analysis,  implementation  (prototyping),  and  experimental  verifi¬ 
cation  are  important  activities  that  need  to  be  done  throughout  the  life  cycle  of  a  real-time 
system.  For  example,  these  activities  can  provide  feedback  during  requirements  analysis, 
help  to  determine  the  feasibility  of  design  alternatives,  and  facilitate  maintenance.  As  the 
design  progresses,  system  behavior  can  be  modeled  with  increasing  accuracy.  A  system 
may  be  incrementally  developed  with  schedulability  analysis  applied  at  each  step.  There¬ 
fore,  a  skeleton  system  can  be  operating  early  in  the  development  phase,  and  the  system 
runtime  behavior  will  always  be  predictable.  To  satisfy  the  need  for  continual  analysis,  the 
system  must  be  instrumented  to  collect  data  about  itself  (e.g.,  performance  data  and 
scheduling  data).  This  requires  that  instrumentation  be  designed  into  the  system  from  the 
beginning. 
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Finally,  when  complementary  analytical  and  experimental  methods  are  used  in  concert  with 
implementation  guidelines  for  Ada  real-time  features,  Ada  has  the  potential  to  be  employed 
successfully  in  the  real-time  domain.  The  analytical  methods  and  associated  Ada  tech¬ 
niques  presented  in  this  article  provide  a  foundation  for  engineering  real-time  systems  in 
Ada  today.  The  REST,  RTSIA,  and  ART  Projects  intend  to  continue  extending  the  schedul¬ 
ing  theory  to  ensure  its  general  applicability  and  to  promulgate  the  resulting  methods  and 
guidelines. 
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